Ce que vous construisez ne vous appartient pas

Petit voyage dans les étages d’une organisation qui paie cher pour aller lentement — et tout ce qu’elle gagnerait à faire autrement

Dans 80 % des cas, l’informatique n’est pas le métier de l’entreprise. C’est un moyen. Un moyen au service d’un retailer, d’un industriel, d’un laboratoire, d’un énergéticien. Pourtant ce moyen consomme énormément, livre lentement, et finit parfois par freiner les ambitions mêmes qu’il était censé servir.

On parle souvent du coût financier. On parle moins du coût en énergie humaine. Or c’est probablement le plus important. Parce que dans la plupart des organisations, ce qui rend les équipes fatiguées, frustrées, désengagées, ce n’est pas la complexité du travail. C’est l’énergie dépensée à compenser ce qui n’a pas été tenu : le besoin mal traduit, le cadre flou, la doc absente, le successeur abandonné.

Ce qui m’intéresse, ce n’est pas de redire que le SI dysfonctionne — tout le monde le sait. C’est de regarder, étage par étage, ce qu’on récupère collectivement quand on accepte de poser un cadre et de le tenir. Pas par discipline. Par intelligence du collectif.

La Ferrari électrique dans les vendanges

Une direction métier exprime un besoin. Le besoin est traduit en langage informatique. Sauf que personne ne s’est assuré que l’émetteur et le récepteur s’étaient bien compris. Résultat : on livre une Ferrari électrique pour aller faire les vendanges dans les champs.

Ce n’est la faute de personne en particulier. C’est l’absence de garantie que les deux parties se sont bien comprises. Le moment de vérification n’a pas été institué. La traduction n’a pas été traitée comme un acte sérieux. On a supposé que ça marcherait — et ça n’a pas marché.

Quand ce moment existe, qu’il est court, structuré, et qu’il appartient au cadre normal du projet, voilà ce qu’on récupère : deux à trois semaines par projet qu’on dépensait habituellement en réunions de rattrapage. Un projet qui ne dérape pas en mois 6 parce qu’on découvre que ce qu’on a livré n’était pas ce qui était attendu. Et surtout, des équipes qui ne portent plus la charge mentale d’un doute permanent sur la commande qu’elles exécutent.

Premier étage : on confond souvent parler ensemble et se comprendre. Le cadre, ici, ne contraint pas. Il libère.

Le besoin du client n’est pas toujours sexy

Deuxième étage. L’IT a compris (ou cru comprendre). Maintenant, il faut livrer. Et là, une autre tension apparaît, plus discrète : le besoin du client n’est peut-être pas sexy. Il faut développer une fonctionnalité en Java, sur des technos qui ne sont pas à la dernière mode, dans un cadre qui n’a rien d’excitant.

Sauf qu’on n’est pas à l’innovation. On n’est pas dans la cellule qui cadre les outils du SI. On est dans une équipe qui travaille sur un produit métier. Le job, c’est que ça marche, dans le budget, avec les outils de la maison.

Et ce budget, soyons clairs : il finance, indirectement, la prime de fin d’année. L’entreprise redistribue une partie de ses bénéfices à ses équipes. Quand le budget tient, c’est aussi le pouvoir d’achat collectif qui tient.

Cela dit — et c’est important — la livraison de la feature dans le cadre n’est pas incompatible avec autre chose. Au contraire. Une équipe qui propose, en parallèle de la nouvelle feature, un peu de cleaning de dette technique et d’obsolescence, ce n’est pas une équipe qui se plaint. C’est une équipe qui anticipe. La dette qu’on n’éteint pas devient le budget qu’on n’aura pas l’année suivante.

Ce qu’on récupère, à cet étage, quand le cadre est clair : la fin du sentiment de double contrainte (“on me demande d’aller vite et de bien faire, sans m’aider à arbitrer”). Une autonomie réelle parce qu’elle s’exerce dans un périmètre lisible. Et la possibilité, pour les profils qui veulent vraiment innover, de savoir où aller — au lieu d’innover en cachette dans un projet qui ne s’y prêtait pas.

Vous n’êtes pas éternel à votre poste

Troisième étage, le plus impensé. Un jour, chacun d’entre nous quittera son poste. Je le souhaite à tout le monde — pour de nouveaux horizons, avec sa fusée sous le bras.

Sauf que la fusée, elle, reste. Et si le mode d’emploi n’a pas été laissé, le successeur galère. Il ne comprend pas comment elle tourne. Il ne sait pas la faire évoluer. Alors il fait ce que tout le monde fait dans cette situation : il ajoute un étage à la fusée, condamne l’ancienne salle machine, en construit une autre — qui sera facturée au métier. Et l’ancien matériel ? Il dort quelque part. On n’a pas pris le temps de le revendre. Dommage pour le portefeuille. Dommage pour la planète.

La documentation, dans ce contexte, n’est pas une corvée administrative. C’est un acte de confiance dans le collectif. Ce n’est pas la doc qui freine — c’est son absence qui ralentit tout le monde, indéfiniment.

Ce qu’on récupère quand la transmission est traitée comme une partie du travail, et non comme un bonus optionnel : des mois de productivité à chaque rotation de poste. La possibilité de partir l’esprit léger, sans la culpabilité (ou la satisfaction trouble) de laisser derrière soi un système que soi seul comprenait. Et accessoirement, des projets qui ne sont plus refacturés deux ou trois fois au métier parce qu’on a oublié ce qu’on avait déjà fait.

Bien sûr, ce qui relève de la confidentialité ou de l’IP de l’entreprise reste dans le coffre, avec les bonnes accréditations. Mais le reste — la connaissance opérationnelle, les choix d’architecture, les raisons des décisions — appartient à l’organisation, pas aux individus.

La trahison silencieuse — et son contraire

Il y a un dernier point, plus humain celui-là. Un successeur qui démarre avec des freins est un successeur qui rame. Qui en veut à son prédécesseur. Et le jour où ces deux personnes se retrouvent — parce que ce monde est petit, surtout dans la tech — la confiance n’est pas au rendez-vous.

À l’inverse, un successeur bien équipé est un allié pour la vie professionnelle. Il vous remerciera dix ans plus tard, dans une conversation imprévue, dans un appel d’offres, dans une recommandation. La transmission n’est pas un coût. C’est un investissement dans son propre réseau futur.

Les dysfonctionnements du SI ne sont pas qu’un problème de méthode ou de gouvernance. Ce sont des dettes laissées par des gens à d’autres gens, dans un système qui a oublié de leur rappeler qu’ils étaient de passage — et qu’ils étaient des maillons d’une chaîne dont la qualité dépend de chacun.

Et puis l’IA est arrivée

Sur ce système déjà fragile, l’IA s’est posée. Et l’IT, par réflexe, l’a traitée comme un outil de plus. Un nouveau langage à apprendre. Un nouveau framework à maîtriser. On a vu fleurir les formations Python, les sessions Mermaid, les ateliers Markdown. Tout le monde devait « s’y mettre ».

Sauf que l’IA n’est pas un outil de plus. C’est un changement de paradigme sur la manière dont la valeur est produite, contrôlée, expliquée et auditée. Ce n’est pas un nouveau Git. C’est un déplacement de la frontière entre ce que l’humain fait et ce que la machine fait.

Et plaquer ce changement de paradigme sur un SI déjà fragile produit deux résultats prévisibles. Soit on pose un pansement sur une jambe de bois — on automatise des processus mal pensés, on génère du code sur une dette technique qu’on n’a pas remboursée, on assiste des utilisateurs qui ne savent toujours pas exprimer leur besoin. Soit on accélère le chaos — on amplifie les biais des données mal gouvernées, les décisions des équipes mal alignées, les erreurs des architectures mal documentées.

Dans les deux cas, on n’a pas transformé. On a accéléré ce qui était.

À l’inverse, l’IA adossée à un SI sain — données de qualité, systèmes sécurisés, expertises solides, gouvernance lisible — devient un véritable game changer. Elle libère du temps sur les tâches sans valeur. Elle augmente le discernement plutôt qu’elle ne le remplace. Elle permet de décider plus vite, mieux, et de manière documentée. Mais cela suppose qu’on ait fait le travail de fond — celui dont parle cet article.

Apprendre l’outil n’est pas un problème. C’est même utile. Mais ce qui transforme une organisation, ce n’est pas l’addition de compétences individuelles sur Python. C’est la capacité collective à décider : ce qu’on demande à l’IA, sur quelles données, avec quelles garanties, sous quelle responsabilité, et au service de quelle ambition.

L’apprentissage de l’outil est un effort individuel. La transformation est un projet collectif.

Ce qu’on récupère ensemble

Posons la question différemment. Pas “qui est en faute”. Mais : qu’est-ce qu’on récupère, collectivement, si l’on accepte de travailler dans un cadre clair, partagé, et tenu ?

On récupère du temps — celui qu’on passe aujourd’hui à compenser, rattraper, redécouvrir, redocumenter. On récupère de l’énergie — celle qu’on dépense à porter une charge mentale qui ne devrait pas être individuelle. On récupère de la confiance — entre les équipes, entre les générations qui se succèdent à un poste, entre le métier et l’IT. On récupère de la lisibilité — sur ce qu’on fait, sur pourquoi on le fait, sur ce qu’il devient quand on n’est plus là pour le porter.

Et accessoirement, on récupère du budget — celui qu’on ne dépense plus en doublons, en sur-ingénierie, en projets refacturés trois fois. Du budget qui revient au métier, à l’innovation réelle, ou à la prime collective.

Travailler dans un cadre clair et partagé, ce n’est pas perdre en autonomie. C’est gagner en énergie. Celle qu’on dépense aujourd’hui à compenser ce que personne n’a tenu.

L’IT n’est qu’un moyen. Mais ce moyen-là engage des budgets, des carrières, des trajectoires d’entreprises et, accessoirement, un peu de la planète. Il mérite peut-être qu’on cesse, à tous les étages, de le traiter comme une affaire individuelle.