Ce que l'IA accélère vraiment

Cet article prolonge une conférence que j'ai récemment donnée au meetup Vue Montréal, où plusieurs échanges m'ont fait prendre conscience à quel point cette tension est répandue.

L'impact le plus intéressant de l'IA dans le développement logiciel n'est pas ce qu'elle produit, mais ce qu'elle modifie dans la façon dont les décisions sont formées, mémorisées et justifiées au fil du temps. Si une grande partie des débats se concentre sur les gains de productivité, la qualité du code ou l'automatisation, le changement le plus profond s'opère au niveau cognitif et organisationnel, où la relation entre l'intention, l'exécution et la responsabilité est subtilement reconfigurée.

Dans nombre d'équipes, la vélocité a augmenté sans inconvénients évidents. Les fonctionnalités sont livrées plus vite, les pull requests sont plus faciles à relire, et le sentiment global de dynamisme est positif. Pourtant, sous cette amélioration apparente, une tension silencieuse émerge. À un moment donné, une question familière mais inconfortable commence à surgir plus souvent : pourquoi cette décision a-t-elle été prise ? Pas comment le code fonctionne, pas s'il est correct, mais pourquoi cette solution particulière a été choisie, sous quelles contraintes, et avec quels arbitrages en tête.

Cette question apparaît rarement en période de crise. Elle ne se manifeste pas comme un test qui échoue ou un déploiement cassé. Elle surgit plus tard, lorsqu'un système doit évoluer, lorsque des hypothèses sont remises en question, ou lorsqu'une nouvelle personne doit comprendre un choix qu'elle n'a pas vécu. C'est à ce moment que l'absence d'intention explicite devient visible, non comme un défaut technique, mais comme une fragilité organisationnelle.

Pendant longtemps, le développement logiciel imposait une forme de friction qui agissait comme un stabilisateur naturel. Écrire du code demandait des efforts, structurer les systèmes exigeait de la prévoyance, et les décisions avaient un coût qui rendait l'hésitation inévitable. Cette friction n'était pas efficace, mais elle obligeait les développeurs et les équipes à ralentir juste assez pour articuler pourquoi une option était préférable à une autre. L'intention et l'exécution étaient étroitement alignées dans le temps, ce qui rendait les décisions plus faciles à mémoriser et à expliquer.

L'IA modifie cet équilibre. En réduisant la distance entre l'intention et l'implémentation, elle permet aux systèmes d'avancer avant que l'intention ait pleinement cristallisé. Les suggestions arrivent instantanément, cohérentes et techniquement acceptables, souvent suffisamment bonnes pour être fusionnées sans résistance. Les décisions ont toujours lieu, mais elles ne requièrent plus la pause qui les rendait autrefois visibles. Ce qui change, ce n'est pas la présence de la réflexion, mais son placement dans le temps. La réflexion est déplacée plutôt que supprimée.

Ce déplacement a d'importantes conséquences. Chaque décision technique existe dans l'un de deux états : explicite ou implicite. Les décisions explicites sont nommées, discutées et externalisées. Elles peuvent être revisitées, contestées et comprises par des personnes qui n'étaient pas présentes au moment où elles ont été prises. Les décisions implicites, en revanche, n'existent que par leurs effets. Elles sont encodées dans la structure, le nommage et le comportement, mais jamais articulées. La plupart des systèmes s'appuient sur des décisions implicites pour fonctionner, et ce n'est pas problématique en soi. Le problème survient lorsque les équipes perdent la capacité de distinguer entre ce qui a été consciemment choisi et ce qui est simplement apparu par défaut.

L'IA accélère la production de décisions implicites. Non parce qu'elle masque l'intention, mais parce qu'elle supprime la friction qui forçait autrefois l'intention à émerger. Quand le code se solidifie rapidement, les résultats deviennent durables avant que leur justification ait été partagée. Avec le temps, cela crée des systèmes syntaxiquement lisibles mais conceptuellement opaques, où le comportement peut être analysé mais où l'intention doit être déduite.

C'est là que la responsabilité devient difficile à localiser. La responsabilité est souvent envisagée en termes d'auteurship ou d'approbation, comme si elle était liée à un moment ou une personne précis. En pratique, la responsabilité dans les systèmes logiciels est temporelle. Elle émerge lorsque quelqu'un doit modifier une décision qu'il n'a pas prise, expliquer un choix qu'il n'a pas vu, ou vivre avec des contraintes dont l'origine est floue. À ce moment-là, l'authorship n'a plus d'importance. Ce qui compte, c'est si la décision a été rendue assez lisible pour survivre au-delà de son contexte d'origine.

Une réponse courante à ce problème est la croyance que l'intention peut toujours être reconstruite plus tard, notamment avec l'aide de l'IA. Si un système devient confus, argumente-t-on, on peut simplement demander à un assistant d'analyser le codebase et de nous l'expliquer. Cette croyance méconnaît la nature de l'explication. L'analyse peut décrire la structure et inférer des motifs, mais elle ne peut pas retrouver une décision qui n'a jamais été externalisée. Une explication générée après coup est une reconstruction, pas un souvenir. Elle produit un récit plausible, pas le raisonnement original façonné par de vraies contraintes, délais et arbitrages.

La mémoire technique ne peut pas être reconstruite rétroactivement. Elle doit être créée au moment où une décision est prise. Cela ne nécessite pas une documentation exhaustive ni un processus lourd. Cela demande de reconnaître quels moments sont des moments porteurs de décision, et de s'assurer qu'ils laissent une trace. Souvent, une seule phrase suffit : une courte note expliquant pourquoi une option a été choisie plutôt qu'une autre, ce qui a été volontairement différé, ou quelle contrainte a dominé la décision. Ces traces ne concernent pas la justification ; elles concernent la durabilité.

Dans ce contexte, le rôle le plus précieux de l'IA n'est pas la génération, mais la révélation. Utilisée de manière délibérée, elle peut aider à faire émerger les zones où les responsabilités sont floues, où l'intention architecturale est imprécise, ou où les décisions sont devenues implicites sans être reconnues. Ce faisant, l'IA n'accélère pas tant la production que la prise de conscience. Mais la prise de conscience seule ne suffit pas. L'acte de nommer et d'assumer une décision reste une responsabilité humaine.

En définitive, le changement le plus profond introduit par l'IA n'est pas technique, mais culturel. Il oblige les équipes à affronter la réalité que nombre de systèmes n'ont jamais été aussi bien compris qu'ils ne le semblaient. Ils tenaient ensemble par un contexte partagé, la proximité et des connaissances non écrites. À mesure que tout cela s'estompe, les décisions implicites s'effondrent, et leur absence devient visible.

La vraie dette technique n'est pas cachée dans du code complexe ou des abstractions obsolètes. Elle est cachée dans le silence. Dans des décisions qui ont été prises mais jamais nommées, dans des choix qui ont fonctionné jusqu'à ce qu'ils ne fonctionnent plus, et dans une intention qui a disparu sans que personne ne s'en aperçoive. L'IA ne crée pas cette dette. Elle la cumule, et ce faisant, offre une opportunité de la voir enfin.