Le paradoxe de l'Agile en R&D
Quand on parle d'Agile, on pense sprints de deux semaines, backlog bien lissé, vélocité mesurée. C'est le monde idéal du logiciel, où un développeur peut livrer un incrément fonctionnel en quelques jours.
En R&D physique — capteurs optiques, équipements de photolithographie, systèmes embarqués — la réalité est différente. Une expérience peut prendre trois semaines. Un composant en rupture de stock bloque une itération entière. Comment, dans ce contexte, appliquer l'Agile sans en trahir l'esprit ?
C'est la question que je me suis posée pendant 14 ans chez KLOÉ, puis chez Bigger Inside.
Ce qui fonctionne : les principes, pas les recettes
L'erreur classique est de vouloir adopter Scrum à la lettre dans un contexte R&D. Ce qui m'a aidé, c'est de revenir aux principes fondateurs plutôt qu'aux cérémonies.
1. Livrer de la valeur fréquemment, même partielle
En R&D, la "valeur" peut être une démonstration de faisabilité, un prototype fonctionnel même imparfait, ou simplement une hypothèse invalidée. L'invalidation rapide d'une hypothèse coûteuse, c'est une vraie livraison de valeur.
2. Rendre visible ce qui est invisible
Sur l'UV-KUB 3, j'ai mis en place un board physique (kanban) où chaque verrou technique avait sa carte. L'équipe — cinq personnes aux profils très différents (techniciens, ingénieurs, docteurs) — visualisait le même état d'avancement. Ça a drastiquement réduit les surprises.
3. Itérer sur l'incertitude plutôt que la fuir
En R&D, on ne sait pas si ça va marcher. L'Agile aide à time-boxer l'incertitude : on donne deux semaines à une hypothèse, puis on décide d'approfondir ou de pivoter. C'est infiniment plus sain que de passer six mois sur un axe qui ne mène nulle part.
Les adaptations indispensables
Sprints plus longs ou hybrides — J'ai utilisé des sprints de 3 à 4 semaines en phase de R&D, raccourcis à 2 semaines dès qu'on approchait de l'industrialisation. Pas de règle absolue : le rythme doit correspondre à la durée naturelle des expériences.
Backlog à deux niveaux — Un backlog "recherche" (hypothèses à tester, axe d'investigation) distinct du backlog "produit" (fonctionnalités à développer). Ça évite de comparer des tâches incomparables.
Définition du "done" adaptée — En R&D, "terminé" peut signifier "l'expérience a été réalisée et les résultats documentés", même si le résultat est négatif. Documenter une hypothèse invalidée, c'est aussi du done.
Le rôle du PM dans ce contexte
Mon rôle n'était pas de protéger l'équipe des contraintes du monde extérieur (comme un PO classique). C'était plutôt d'être traducteur : entre les contraintes business (coût cible, délai, compétiteurs), les contraintes techniques (faisabilité, physique des matériaux) et les contraintes humaines (charge de travail, compétences disponibles).
Ce rôle de traducteur, il demande une vraie compréhension des deux côtés. C'est ce que m'a apporté ma formation d'ingénieur couplée à l'expérience managériale.
Ce que j'ai appris
La rigueur scientifique et l'Agile ne sont pas opposés. Ils partagent la même valeur fondamentale : l'empirisme. Tester, mesurer, ajuster. La différence, c'est l'échelle de temps et la nature des artefacts produits.
Ce qui compte, c'est d'adapter le cadre à la réalité du terrain — et non l'inverse.