Du canard en plastique à l'audit SI : pourquoi l'explicitation est la compétence la plus sous-estimée en ingénierie logicielle

Des milliers de développeurs déboguent leur code en parlant à un canard en plastique. Derrière cette anecdote se cache un mécanisme cognitif puissant — l’explicitation — qui, pratiqué à l’échelle d’un projet, distingue les réalisations maîtrisées des dérapages coûteux. Du bureau du développeur jusqu’à l’audit de votre système d’information, cet article explore comment rendre explicite ce qui reste implicite à chaque niveau de votre SI.

Des milliers de développeurs à travers le monde déboguent leur code en parlant à un canard en plastique. La technique a un nom — le rubber duck debugging — et elle fonctionne remarquablement bien. Mais derrière cette anecdote qui prête à sourire se cache un mécanisme cognitif puissant que la plupart des organisations sous-exploitent : l’explicitation, c’est-à-dire l’acte de formuler clairement, à voix haute ou par écrit, ce que l’on croit savoir. Ce mécanisme, quand il est pratiqué à l’échelle individuelle, permet à un développeur de retrouver un bug en quelques minutes. Quand il est pratiqué à l’échelle d’un projet, il permet d’éviter des mois de dérive et des dizaines de milliers d’euros de corrections.

Cet article explore cette montée en échelle : de la technique de debug individuelle jusqu’aux méthodologies d’analyse qui structurent les projets d’applications métier. En chemin, nous verrons pourquoi l’implicite est le premier facteur d’échec des projets IT en PME, et comment une discipline rigoureuse d’explicitation — à chaque niveau de votre système d’information — constitue un levier de performance que peu d’entreprises exploitent pleinement.

Le rubber duck debugging : une technique sérieuse derrière l’anecdote

L’histoire est devenue célèbre dans la communauté des développeurs. Dans leur ouvrage de référence The Pragmatic Programmer, Andrew Hunt et David Thomas racontent le cas d’un développeur qui transportait un canard en plastique avec lui et déboguait son code en lui expliquant son raisonnement, ligne par ligne. L’idée est d’une simplicité désarmante : quand vous êtes bloqué sur un bug, prenez n’importe quel objet — un canard, une tasse, un collègue patient — et expliquez-lui exactement ce que votre code est censé faire, étape par étape. Dans une proportion surprenante de cas, le simple fait de verbaliser révèle l’erreur avant même d’avoir terminé l’explication.

Pourquoi cela fonctionne-t-il ? Parce que lorsqu’un développeur lit son propre code, il le fait en mode reconnaissance. Son cerveau complète automatiquement les blancs, saute les évidences, et reconstruit une cohérence qui n’existe parfois que dans sa tête. C’est un biais cognitif bien documenté : nous voyons ce que nous nous attendons à voir, pas ce qui est réellement écrit. La verbalisation brise ce cercle. Elle force un changement de registre mental — on passe du mode “je sais ce que fait mon code” au mode “est-ce que je peux démontrer ce que fait mon code à quelqu’un qui ne sait rien”. Et c’est dans cet écart entre les deux modes que les bugs se révèlent.

Ce qui est remarquable, c’est que le niveau technique de l’interlocuteur n’a strictement aucune importance. Le canard ne comprend rien, et c’est précisément pour cela qu’il est efficace. Ce n’est pas l’échange qui produit la découverte, c’est l’effort d’explicitation lui-même. Le développeur qui dit “ici, je parcours toute la liste” et réalise en l’énonçant qu’il s’arrête en réalité un élément trop tôt ne reçoit aucune aide extérieure. Il a simplement rendu explicite ce qui était resté implicite dans son raisonnement.

Cette mécanique est directement liée à ce que l’on appelle la maîtrise du code propre. Un code lisible et bien structuré, c’est un code qui a été, d’une certaine manière, déjà “expliqué au canard” en amont. Le nommage explicite des variables, la clarté des fonctions, la documentation inline — tout cela participe du même principe : rendre visible et vérifiable ce que le développeur avait dans la tête au moment de l’écriture. Le code propre est de l’explicitation préventive.

L’implicite, ce saboteur silencieux des projets IT

Si un développeur seul a besoin d’un canard en plastique pour débusquer ses propres hypothèses cachées dans quelques dizaines de lignes de code, il est légitime de se demander ce qu’il se passe à l’échelle d’un projet qui implique un donneur d’ordre, un ou plusieurs chefs de projet, une équipe de développement et des utilisateurs finaux. La réponse est simple : l’implicite se multiplie à chaque interface humaine, et ses effets se cumulent de manière exponentielle.

Prenons un exemple courant. Un dirigeant de PME demande à son prestataire de “refaire le CRM”. Pour lui, cela signifie automatiser le suivi commercial et intégrer les données du site web. Pour le chef de projet, cela signifie migrer les données existantes et construire de nouveaux tableaux de bord. Pour le développeur, cela signifie choisir un framework, concevoir un modèle de données et développer des interfaces. Chacun avance avec sa propre compréhension du “refaire le CRM”, et pendant les premières semaines, tout le monde a l’impression d’être aligné. C’est plusieurs mois plus tard, lors des premiers tests utilisateurs, que l’on découvre les divergences. Le coût de correction est alors sans commune mesure avec ce qu’aurait coûté une explicitation rigoureuse au démarrage.

Ce phénomène touche plusieurs dimensions d’un projet. Il y a d’abord l’implicite fonctionnel : les processus métier que “tout le monde connaît” mais que personne ne décrit exactement de la même façon. Un commercial qui dit “je qualifie un prospect” ne met pas forcément les mêmes étapes derrière cette expression que son directeur ou que l’équipe technique qui doit traduire ce processus en fonctionnalités. C’est pourquoi comprendre les processus métier et les règles associées constitue un préalable non négociable avant toute ligne de code.

Il y a ensuite l’implicite technique : les choix d’architecture hérités que personne ne questionne plus parce qu’ils “ont toujours été comme ça”. Une base de données dont le schéma reflète les contraintes d’un logiciel remplacé il y a cinq ans. Un flux d’intégration qui contourne un bug jamais corrigé. Ces décisions implicites, accumulées au fil du temps, constituent le terreau de ce que l’on appelle la dette technique — et l’explicitation est le premier levier pour la réduire.

Il y a enfin l’implicite humain, peut-être le plus insidieux. Les résistances au changement qui ne s’expriment pas ouvertement, les craintes de perte de compétence ou de contrôle, les non-dits politiques au sein des équipes. Quand un utilisateur clé freine un projet sans raison apparente, c’est rarement par mauvaise volonté. C’est souvent parce qu’il n’a pas les mots — ou pas l’espace — pour formuler ce qui le préoccupe. La réticence en gestion de projet masque souvent une incapacité collective à verbaliser les enjeux réels, exactement comme un développeur bloqué qui “sent” qu’il y a un problème sans parvenir à l’identifier.

L’explicitation comme méthodologie projet : du canard au bureau d’étude

Si le canard en plastique est la version artisanale de l’explicitation, ce que fait un bureau d’étude en phase d’analyse constitue sa version industrielle. Le mécanisme est le même : on place l’interlocuteur — ici, l’organisation cliente — dans une situation où il doit formuler explicitement ce qui relève habituellement de l’implicite. Mais les outils et la rigueur sont d’un tout autre ordre.

Chez Agerix, cette discipline d’explicitation commence bien avant la première ligne de code, avec l’étude de faisabilité. Cette analyse structurée en quatre volets — technique, économique, commercial, financier — fonctionne exactement comme une session de rubber ducking à l’échelle du projet. On ne demande pas au client “que voulez-vous ?”, question qui appelle des réponses vagues et chargées d’implicite. On lui demande de démontrer, volet par volet, que son projet tient debout. Et c’est dans cet effort de démonstration que les incohérences émergent, bien avant qu’elles ne se transforment en retards ou en surcoûts.

Le parallèle va plus loin. Le développeur qui parle à son canard adapte intuitivement son niveau d’explication à la complexité du code qu’il examine. Un bureau d’étude fait la même chose, mais de manière formalisée. Le framework Cynefin, que nous utilisons pour qualifier le niveau de complexité d’un projet, détermine le type d’explicitation requis. Un projet relevant du domaine “simple” nécessite une documentation classique des processus. Un projet “compliqué” appelle une analyse experte approfondie. Un projet “complexe” requiert une approche exploratoire où l’explicitation se fait par itérations successives, chaque cycle révélant de nouvelles dimensions du problème.

Pour illustrer concrètement ce mécanisme, prenons le cas d’un projet d’application métier sur mesure pour une PME. Le dirigeant exprime un besoin apparemment clair : “nous avons besoin d’un outil pour gérer nos devis et nos commandes”. Lors de la phase d’analyse, en le faisant verbaliser chaque étape de son processus commercial — qui intervient, à quel moment, avec quelles données, selon quelles règles — on découvre que le processus réel est significativement plus complexe que le processus perçu. Il y a des exceptions non documentées, des validations informelles, des flux d’information qui passent par des tableurs parallèles. Sans cette phase d’explicitation, l’application livrée aurait répondu au besoin tel qu’il était exprimé, pas au besoin tel qu’il existe réellement. Et la différence entre les deux, c’est celle qui sépare un outil adopté par les équipes d’un outil contourné dès la première semaine.

Intégrer l’explicitation à chaque échelle de votre SI

La force de l’approche par l’explicitation est qu’elle s’applique de manière cohérente à quatre échelles distinctes d’un système d’information. Ce qui change, ce ne sont pas les principes, ce sont les outils et le niveau de formalisation.

À l’échelle du code individuel, c’est le rubber duck debugging dans sa forme originale, complété par les revues de code entre pairs et la documentation inline. Un développeur qui nomme une variable remainingAttempts plutôt que n pratique l’explicitation. Un commentaire qui explique le “pourquoi” d’un choix technique (et non le “quoi”, que le code doit porter lui-même) est un acte d’explicitation. Les équipes qui intègrent ces pratiques réduisent mécaniquement le temps de compréhension du code par d’autres développeurs, ce qui a un impact direct sur les coûts de maintenance.

À l’échelle du composant ou du module, l’explicitation prend la forme des tests unitaires et des contrats d’API. Un test unitaire bien rédigé est littéralement une explication formelle de ce que le composant doit faire : étant donné telles conditions initiales, quand telle action se produit, alors tel résultat est attendu. C’est du rubber ducking automatisé et vérifiable. Les contrats d’API jouent le même rôle aux interfaces entre systèmes : ils rendent explicites les attentes de chaque partie, éliminant les malentendus avant qu’ils ne se manifestent en production.

À l’échelle du projet, l’explicitation s’incarne dans les méthodologies de cadrage et de pilotage. Le kick-off meeting est le moment où toutes les parties prenantes doivent verbaliser leur compréhension du projet — et où les divergences, si elles sont traquées avec méthode, peuvent encore être résolues à moindre coût. La matrice RACI rend explicite ce que chacun présuppose souvent : qui est responsable de quoi, qui décide, qui est consulté, qui est informé. Sans cette formalisation, les zones grises prolifèrent et deviennent des zones de conflit.

À l’échelle du système d’information dans son ensemble, l’explicitation se traduit par la cartographie applicative, l’audit de dette technique et la documentation d’architecture. Une entreprise capable de répondre clairement à la question “comment vos systèmes communiquent-ils entre eux et pourquoi ont-ils été conçus ainsi ?” est une entreprise qui maîtrise son SI. Celles qui ne peuvent pas répondre — et elles sont nombreuses parmi les PME — découvrent cette absence d’explicitation le jour où un composant tombe en panne, où un prestataire clé change, ou où un nouveau besoin métier révèle les limites d’une architecture jamais documentée.

L’explicitation n’est pas un luxe, c’est un investissement

Il serait tentant de considérer cette discipline comme un surcoût, un effort supplémentaire dans des projets déjà contraints par les délais et les budgets. C’est une erreur de perspective. Le coût de l’implicite est bien réel, mais il est diffus et différé, ce qui le rend invisible dans les tableaux de bord classiques. Il se manifeste sous forme de spécifications à reprendre, de fonctionnalités à refaire, de formations utilisateurs rallongées parce que l’outil ne correspond pas aux pratiques réelles, de dette technique accumulée par des choix non documentés.

Les PME qui investissent dans l’explicitation — que ce soit en formant leurs développeurs aux pratiques de code propre, en structurant leurs phases d’analyse avec un partenaire compétent, ou en documentant leurs processus métier avant de les automatiser — constatent des retours mesurables. Des phases de recette plus courtes, des taux d’adoption utilisateur plus élevés, des coûts de maintenance réduits, et surtout une capacité à faire évoluer leurs outils sans tout reconstruire à chaque itération.

Le canard en plastique, au fond, nous rappelle quelque chose de fondamental. La rigueur intellectuelle en ingénierie logicielle ne commence pas par un choix de technologie ou un framework à la mode. Elle commence par un acte simple, presque humble : formuler clairement ce que l’on croit savoir, et vérifier que cette formulation résiste à l’examen. Les développeurs qui pratiquent le rubber ducking le font instinctivement. Les organisations qui institutionnalisent ce principe à chaque échelle de leur système d’information sont celles qui livrent des projets maîtrisés, dans les délais, et qui génèrent la valeur attendue.

Chez Agerix, c’est ce rôle que nous endossons auprès de nos clients. Nous sommes, d’une certaine manière, leur canard en plastique — un canard qui pose les bonnes questions, qui structure les réponses, et qui transforme l’implicite en spécifications exploitables. Parce que dans le développement d’applications métier, ce qui n’a pas été dit coûte toujours plus cher que ce qui a été dit trop tôt.