30/03/2026
Question sincère pour les CTOs et Engineering Managers qui gèrent un SI en croissance :
Pouvez-vous expliquer en 3 phrases comment vos systèmes communiquent entre eux — et pourquoi ils ont été conçus ainsi ?
Je pose cette question régulièrement en début de mission. Et la réponse la plus fréquente, c'est un silence gêné suivi de "il faudrait demander à [personne qui a quitté l'entreprise il y a 2 ans]".
Ce n'est pas un problème de compétence. C'est un problème d'explicitation.
Dans une scale-up qui passe de 30 à 100 personnes, chaque nouveau collaborateur, chaque nouveau module, chaque intégration ajoute une couche d'implicite. Des choix d'architecture que plus personne ne questionne. Des flux entre systèmes qui contournent un bug jamais corrigé. Des processus métier que "tout le monde connaît" — mais que personne ne décrit exactement de la même façon.
Et tant que tout fonctionne, personne ne s'en inquiète. C'est le jour où un composant tombe, où un prestataire change, ou où un nouveau besoin révèle les limites d'une architecture jamais documentée que le coût de cet implicite explose.
Alors je suis curieux :
À quel moment avez-vous réalisé que votre SI contenait plus d'implicite que vous ne le pensiez ? Qu'est-ce qui a déclenché cette prise de conscience ?
Cette question est au cœur d'un article que j'ai écrit sur l'explicitation en ingénierie logicielle — la discipline qui consiste à rendre visible ce qui reste dans les têtes, à chaque échelle du SI.
J'y détaille un framework à 4 niveaux (code → composant → projet → SI global) avec des méthodologies concrètes pour chaque échelle : du nommage de variables jusqu'à la cartographie applicative, en passant par le kick-off structuré et la matrice RACI.
👉 https://www.agerix.fr/blog/du-canard-en-plastique-a-laudit-si-pourquoi-lexplicitation-est-la-competence-la-plus-sous-estimee-en-ingenierie-logicielle?utm_source=linkedin&utm_medium=social&utm_campaign=post-question-engagement&utm_content=profil-personnel
Si votre réponse à ma question vous a mis un peu mal à l'aise, l'article devrait vous donner des pistes concrètes pour y remédier.
Du rubber duck debugging à l'analyse de projet : découvrez pourquoi l'explicitation structurée est le mécanisme qui distingue les projets IT maîtrisés de ceux qui déraillent, à chaque échelle de votre SI.