Ce que les bilans de projet ne capturent pas
À la fin d’un projet, la plupart des équipes produisent un bilan. On liste ce qui a bien fonctionné, ce qui a posé problème et les actions correctives à mettre en place. Le périmètre a dérapé? On renforce le processus de contrôle des changements. La communication avec le sponsor était déficiente? On prévoit des points hebdomadaires dès le prochain projet. Ces ajustements sont utiles, mais ils partagent une limite commune: ils ne touchent jamais aux hypothèses qui ont guidé les décisions initiales.
Chris Argyris, chercheur à Harvard, a formalisé cette distinction dans les années 1970 avec Donald Schön. Leur cadre distingue deux modes d’apprentissage organisationnel. L’apprentissage en boucle simple (single-loop learning) consiste à corriger les écarts par rapport aux normes et procédures en vigueur, sans remettre en question ces normes elles-mêmes. L’apprentissage en double boucle (double-loop learning) va plus loin: il interroge les valeurs, hypothèses et objectifs qui ont produit le problème en premier lieu.
Boucle simple: corriger sans comprendre
La boucle simple fonctionne comme un thermostat. La température s’écarte de la consigne, le système corrige. En gestion de projet, cela se traduit par des ajustements de processus après chaque difficulté rencontrée: quand le planning dérive, on introduit un suivi plus serré; quand les livrables sont incomplets, on ajoute une revue de qualité. L’approche est logique et souvent nécessaire.
Le problème apparaît quand les mêmes catégories de difficultés reviennent d’un projet à l’autre malgré les ajustements accumulés. Le contrôle des changements est de plus en plus rigoureux, mais le périmètre continue de dériver. Les réunions de suivi se multiplient, mais les mauvaises nouvelles arrivent toujours trop tard au comité de pilotage. Chaque nouveau correctif traite le symptôme visible sans interroger la logique sous-jacente.
Pourquoi les professionnels expérimentés résistent à la double boucle
Argyris a observé un paradoxe contre-intuitif: les professionnels les plus compétents sont souvent les plus réticents à remettre en question leurs hypothèses. Leur parcours de succès continus leur a rarement offert l’occasion de développer les réflexes nécessaires face à l’échec. Quand un projet ne se passe pas comme prévu, la réaction spontanée est de chercher des causes externes (le client a changé d’avis, les ressources étaient insuffisantes, la direction n’a pas soutenu le projet) plutôt que d’examiner ses propres présupposés.
Argyris décrit ce phénomène à travers la distinction entre théorie professée (espoused theory), ce qu’une personne dit faire et valoriser, et théorie en usage (theory-in-use), ce que son comportement réel révèle. Un chef de projet peut affirmer qu’il encourage la transparence tout en filtrant systématiquement les informations négatives avant de les transmettre à sa hiérarchie. L’écart entre les deux théories reste invisible tant que personne ne le questionne explicitement.
Les routines défensives en comité de pilotage
Les organisations développent des routines défensives, des comportements collectifs qui protègent les individus de l’embarras ou de la remise en cause, mais qui bloquent l’apprentissage réel. En gestion de projet, ces routines sont particulièrement visibles dans les instances de gouvernance.
En comité de pilotage, les présentations d’avancement tendent à minimiser les risques réels. Les indicateurs passent de vert à orange puis à rouge avec un retard systématique par rapport à la réalité. Les bilans de phase attribuent les difficultés à des facteurs conjoncturels plutôt qu’à des choix structurels discutables. L’équipe projet évite d’aborder les tensions avec le sponsor ou les faiblesses du modèle de gouvernance retenu, parce que ces sujets exposeraient des décisions prises en amont par des personnes présentes dans la salle.
Ce fonctionnement n’est pas le résultat de la mauvaise foi individuelle. Il reflète un système où les incitations implicites découragent la remise en question. Pointer un problème structurel revient souvent à désigner un responsable, ce que la plupart des cultures organisationnelles rendent coûteux sur le plan personnel.
Passer à la double boucle en pratique
Transformer un bilan de projet ou une rétrospective en exercice de double boucle suppose de modifier la nature des questions posées. Au lieu de demander “qu’est-ce qui n’a pas fonctionné et comment le corriger?”, on demande: “quelles hypothèses avons-nous formulées au départ, et lesquelles se sont révélées fausses?”
Quand le périmètre dérive de manière récurrente, la question en double boucle n’est pas “comment mieux contrôler les changements?” mais “pourquoi notre processus de cadrage initial produit-il systématiquement un périmètre instable? Notre hypothèse sur la maturité du besoin client était-elle correcte?” Quand les délais sont systématiquement dépassés, au lieu de chercher à mieux estimer les charges, on peut se demander si le modèle contractuel retenu (forfait, régie, cadre agile) est adapté au niveau d’incertitude réel du projet.
Ce type de questionnement exige ce qu’Amy Edmondson, professeure à Harvard, appelle la sécurité psychologique: la conviction partagée que l’on peut exprimer des doutes ou signaler une erreur sans risquer de représailles. Sans cette condition préalable, les participants d’un bilan restent en boucle simple par instinct de protection.
Modèle I et Modèle II: deux modes de fonctionnement
Argyris a complété son cadre avec la distinction entre deux modèles de comportement organisationnel. Le Modèle I repose sur le contrôle unilatéral: chaque acteur cherche à garder la maîtrise de la situation, à protéger sa position et à éviter de perdre la face. Les décisions sont prises sur la base de raisonnements qui ne sont pas exposés aux autres pour validation. La plupart des organisations fonctionnent en Modèle I sans le reconnaître.
Le Modèle II, à l’inverse, repose sur l’enquête partagée. Les acteurs exposent leur raisonnement, testent leurs hypothèses publiquement et acceptent que leurs conclusions puissent être invalidées. En gestion de projet, cela se traduit par des revues où le chef de projet expose ce qu’il recommande et les hypothèses sur lesquelles repose sa recommandation, en invitant explicitement les parties prenantes à les contester.
La transition du Modèle I au Modèle II ne se décrète pas. Elle se construit progressivement, en commençant par de petits exercices: demander à chaque participant d’un bilan de formuler une hypothèse initiale qui s’est révélée fausse, ou interroger systématiquement les décisions qui “allaient de soi” au lancement du projet.
Ce que les méthodes agiles apportent et ce qu’elles ne résolvent pas
Les rétrospectives agiles, inscrites dans le douzième principe du Manifeste Agile (“à intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace”), créent un cadre propice à l’apprentissage itératif. Leur fréquence régulière et leur format participatif facilitent l’identification des dysfonctionnements.
Pourtant, la majorité des rétrospectives restent en boucle simple. Elles produisent des listes d’actions correctives (améliorer la définition de done, réduire le travail en cours, mieux documenter les user stories) sans remonter aux hypothèses fondamentales. Pourquoi l’équipe a-t-elle choisi ce découpage en sprints? Le Product Owner dispose-t-il réellement de l’autorité décisionnelle que le cadre Scrum lui attribue? Le modèle de collaboration retenu avec le client est-il compatible avec le niveau d’incertitude du produit?
Poser ces questions dans une rétrospective de sprint exige un facilitateur capable de sortir l’équipe du mode résolution de problèmes pour entrer dans un mode questionnement des présupposés. Il ne s’agit pas de le faire à chaque itération, mais d’y consacrer une rétrospective sur trois ou quatre, en préparant explicitement le terrain pour que les participants sachent que les hypothèses structurelles sont ouvertes à la discussion.