L'IA est un amplificateur, pas une direction.

Auteur et source de l'article : InfoQ

L'IA vous permet d'écrire du code 10 fois plus vite, et ensuite ? Plus de code signifie des temps de compilation plus longs, des tests plus lourds, des revues de code plus bloquées, et une base de code incompréhensible. Le logiciel est une dette : plus vous écrivez vite, plus vous accumulez.

L'avertissement d'Adam Bender, ingénieur logiciel principal chez Google, est direct : la manière dont vous construisez des logiciels aujourd'hui ne fonctionnera tout simplement pas à une vitesse 10 fois supérieure. Mais les véritables gagnants de l'ère de l'IA ne sont pas les équipes les plus productives, mais celles qui ont les fondamentaux les plus solides. Car l'IA ne fait que amplifier, elle ne détermine pas la direction.

Lors d'une conférence plénière à Google I/O 2026, Adam Bender a posé une question à laquelle la plupart des gens n'ont pas encore eu le temps de réfléchir : lorsque l'IA pousse la vitesse de production de code au-delà de la capacité des processus d'ingénierie existants, quel élément de notre écosystème de développeurs s'effondrera en premier ? Il a lié l'ensemble de sa conférence autour d'un concept que vous n'avez peut-être jamais entendu : l'écologie logicielle, discipline qui étudie de manière globale l'écosystème sociotechnique de la production logicielle. Autrement dit, il ne s'agit pas seulement d'examiner la technologie, mais aussi les personnes, la culture et les règles implicites au sein des organisations. Sur la base de la vidéo de cette conférence, InfoQ a organisé le contenu.

Les points clés sont les suivants :

• L'IA ne résout pas automatiquement vos problèmes. Si vos pratiques sont bonnes, elle les amplifie. Mais si elles ne le sont pas, elle ne fait que créer davantage de problèmes.
• Il est génial que tout le monde soit un constructeur, jusqu'au moment où tu dois maintenir tout ce que tout le monde a construit.
• Les pratiques techniques ne sont pas sacrées. Les pratiques changent, les principes sont ce qui compte.
• En tant qu'ingénieur logiciel sur le terrain, à ce moment critique, vous êtes au cœur de la décision sur l'avenir de l'ingénierie logicielle. Des outils aux flux de travail, des pratiques d'ingénierie à la culture d'ingénierie, si vous comprenez les systèmes en marche, vous trouverez des leviers.

Qu'est-ce que le « système » ?

Votre travail en 2026 est complètement différent de ce que vous imaginiez en 2020. Si j'essayais d'expliquer à mon moi de 2020 ce qui se passe aujourd'hui, je n'aurais pas cru mes propres mots. Les changements sont trop nombreux, trop intenses pour être facilement assimilés. Je ne peux pas prédire l'avenir, mais je crois que si nous étudions attentivement l'écosystème logiciel actuel, certaines réponses sont plus proches que nous ne le pensons.

Aujourd’hui, je veux discuter avec vous d’un mot : l’écologie logicielle (Software Ecology). Cela peut sembler comme un terme que j’ai inventé pour monter sur scène, mais ce n’est pas le cas — c’est un terme sérieux. Avant d’en donner une définition, je souhaite d’abord établir un contexte en approfondissant légèrement la pensée systémique.

Un système est un ensemble d'éléments interconnectés qui fonctionnent selon un ensemble de règles pour former un tout cohérent. Cela peut sembler abstrait, mais vous n'êtes pas étranger aux systèmes. Par exemple, une climatisation : un thermostat qui connaît la température cible, un système de chauffage, de ventilation et de climatisation qui réchauffe ou refroidit, une pièce, et lorsque la température est appropriée, le signal s'arrête — voilà un système.

Si vous êtes ingénieur logiciel, vous travaillez chaque jour avec des systèmes : vous concevez des systèmes, les construisez, les faites fonctionner, et au cours de ce processus, vous avez probablement appris une chose : tout est connecté.

Ensuite, il y a l'écosystème, un système particulier. La définition est un peu longue, mais elle est importante : un écosystème est un réseau dynamique d'acteurs interdépendants qui coévoluent avec leur environnement, caractérisé par des comportements émergents et une autonomie décentralisée. En termes simples, un écosystème est complexe, avec des composants profondément interconnectés, chacun possédant sa propre autonomie pour prendre des décisions et agir. Et le point le plus crucial : l'environnement fait partie intégrante du système ; vous ne pouvez pas les séparer.

Un écosystème est également un système complexe adaptatif capable de croître, de se modifier et d'évoluer au fil du temps. Ils possèdent également une caractéristique appelée propriété émergente : il s'agit de quelque chose que vous ne pouvez pas observer en examinant un seul composant individuel ; il ne devient apparent que lorsque l'ensemble du système est assemblé. C'est précisément cette évolution continue, cet apprentissage constant et cette émergence qui rendent extrêmement difficile la compréhension de ce qui se passe réellement au sein d'un écosystème.

En parlant d'écosystème, vous pensez probablement aux montagnes, aux rivières, au chant des oiseaux et aux fleurs parfumées. Mais l'environnement interne des développeurs est également un écosystème : il comprend divers outils et services, des personnes avec leurs propres idées et besoins, ainsi que des contraintes métier. Et c'est un système particulier : un système socio-technique, c'est-à-dire un système composé à la fois d'humains et de technologies. Les systèmes socio-techniques sont extrêmement complexes, car vous commencez avec toutes ces technologies, puis vous y intégrez les êtres humains.

Vous avez probablement déjà été en contact avec l’intelligence des systèmes socio-techniques sans même vous en rendre compte. Connaissez-vous la loi de Conway : la technologie qu’une organisation construit reflète sa structure de communication interne. En termes simples, si vous avez quatre équipes qui travaillent sur le même compilateur, vous obtiendrez un compilateur en quatre passes — c’est ainsi que ça fonctionne. L’observation fondamentale de la loi de Conway est que la manière dont nous construisons la technologie est indissociable de la structure de l’organisation qui la construit ; l’organisation façonne ce qui est finalement créé.

Mais ce n’est pas seulement la structure organisationnelle qui influence l’écosystème des développeurs ; les valeurs et la culture ont également un impact profond. L’écosystème que vous construisez reflète ce que votre organisation incite à faire, et votre culture d’ingénierie crée l’environnement autour de l’écosystème des développeurs. Une fois que vous comprenez les systèmes socio-techniques, vous les voyez partout dans le développement logiciel : architecture, culture d’analyse des incidents, revues de code, stratégies de sécurité — partout. Ce que nous construisons, ainsi que la manière dont nous choisissons de le construire, reflète ce que nous valorisons. Si nous faisons preuve de suffisamment d’attention, nous pouvons utiliser cette compréhension pour amplifier nos valeurs et les intégrer dans ce que nous construisons.

Je peux maintenant vous donner une définition correcte : l’écologie logicielle est la discipline qui étudie de manière globale l’écosystème socio-technique de la production de logiciels. Si ce qui précède semble un peu abstrait, pas de souci, examinons maintenant un cas réel.

L'écosystème de développeurs de Google

Je parle de Google non pas parce que j'y travaille et que je dois le défendre, mais parce que c'est l'écosystème de développeurs que je connais le mieux. Mon objectif n'est pas de vous dire de copier Google, car cela ne vous serait pas bénéfique. Vous êtes des entreprises différentes, à des stades différents, et vous faites face à des compromis différents. Beaucoup des choix faits par Google étaient spécifiquement adaptés aux besoins que nous avions lors de la construction de notre écosystème à l'époque.

Il y a quelques années, nous avons écrit un livre, interne, appelé « le livre du flamant rose ». La moitié du livre traitait du contrôle de version et des tests, mais la première moitié entière était consacrée à la culture d’ingénierie. Beaucoup se demandaient pourquoi nous consacrions autant de pages à la culture, car si vous ne comprenez pas la culture de Google, vous ne pouvez pas comprendre pourquoi nous avons fait ces choix techniques — ces éléments sont interconnectés.

Google possède plusieurs traits culturels uniques. Nous sommes profondément orientés vers l'ingénierie, et les ingénieurs sont toujours présents lors de la prise de décisions importantes ; nous accordons une extrême importance à la transparence, en rendant autant que possible tous les documents et le code accessibles à tous ; nous encourageons l'entraide : en effet, toute personne ayant quitté Google mentionnera en premier lieu la bienveillance de ses collègues ; nous considérons les revues de code comme des opportunités d'encadrement, et non comme des corrections de devoirs ; nous accordons une grande importance à la standardisation ; nous croyons en l'amélioration continue ; nous privilégions les rétrospectives d'incidents sans recherche de responsabilités ; nous sommes convaincus que la durabilité prime sur l'heroïsme, et que l'automatisation est préférable au travail manuel. Bien sûr, nous n'atteignons pas toujours tous ces idéaux, mais c'est vers cette direction que nous nous efforçons culturellement de progresser.

Sur le plan technique : un seul dépôt de code monolithique contenant presque tout le code ; développement basé sur la branche principale, avec chaque modification intégrée directement dans la branche principale ; lors de la construction d’un binaire, presque chaque ligne de code est compilée à partir des sources ; une chaîne d’outils de construction uniforme utilisée par tous ; une plateforme mondiale d’automatisation des tests, où tous les tests sont exécutés en un seul endroit, avec des milliards de cas de test chaque jour ; un signal global « dernier vert » permettant de vous indiquer l’état de n’importe quelle construction via un simple site interne ; un environnement de calcul uniforme, rendant pratiquement impossible le problème « ça marche sur ma machine » ; des cadres de développement hautement normalisés et un petit ensemble de langages de programmation principaux.

Ce mélange de culture et de technologie a fait de Google ce qu'il est aujourd'hui ; vous ne pouvez pas comprendre la moitié sans ignorer l'autre.

Partager le destin

Si je devais choisir un principe qui nous guide constamment en arrière-plan, ce serait « Shared Fate » (destin partagé). Il décrit le degré d'interdépendance entre un écosystème et ses composants ; dans un écosystème à fort destin partagé, un composant peut influencer tous les autres. Dans l'écosystème des développeurs, le destin partagé est à la fois un choix technique et un choix social. Vous ne pouvez pas simplement réaliser un destin partagé en faisant en sorte que tout le monde utilise la même technologie ; vous devez également établir un contrat social sur la manière de gérer ces technologies.

Chez Google, le destin partagé commence par un dépôt de code unique. Toutes les lignes de code de l'entreprise, à l'exception de quelques cas comme Android et Chrome, se trouvent dans un seul dépôt partagé. Tous les commits sont effectués sur la branche principale, sans branches ni numéros de version ; tout est centralisé. Ce destin partagé nous permet d'appliquer un correctif de sécurité dans un seul fichier et d'être certains qu'au bout d'une semaine, chaque application de l'entreprise sera corrigée. Réparer dix lignes de code pour corriger dix milliards de lignes d'applications et de logiciels système, c'est comme avoir un superpouvoir.

Mais partager un sort n'est pas toujours une bonne chose, c'est un choix. Il existe des endroits où partager un sort n'est pas approprié, comme en production, où nous ne voulons jamais qu'un service entraîne la chute de tous les autres, ou qu'un cluster infecte toute une région. Nous avons donc investi beaucoup d'efforts pour éviter les partages de sort dangereux, ceux qui provoquent des pannes en cascade. Partager un sort est un compromis : vous devez trouver le bon emplacement, puis vous assurer qu'il fonctionne à votre avantage.

Changement à grande échelle

L'une des propriétés émergentes les plus intéressantes dans notre environnement partagé est le changement à grande échelle. Notez ceci : bien avant l'apparition de l'IA, les outils internes de Google permettaient déjà à un développeur de modifier des millions de lignes de code, des millions de lignes qu'il ne lirait jamais, ne reverrait jamais et dont il pourrait ne rien connaître. Nous avons construit des outils qui rendent tout cela automatiquement possible, et c'est ainsi aujourd'hui, et nous le faisons depuis au moins quinze ans.

Cette capacité nous permet d’évoluer continuellement le dépôt de code monolithique, de mettre à jour les langages et les frameworks, et d’éviter que notre environnement interne ne devienne rigide. Sans ces changements à grande échelle, nous ne serions pas Google d’aujourd’hui. Les collègues qui développent ces outils accomplissent un travail d’arrière-plan héroïque, permettant à l’entreprise d’avancer à la vitesse nécessaire.

Mais l'essentiel est que vous ne pouvez pas vraiment le comprendre si vous ne maîtrisez pas les composants culturels et techniques qui rendent les changements à grande échelle possibles. De quoi avez-vous besoin ? Une culture de test généralisée, où tout le monde écrit des tests. Une plateforme de test unifiée, pour savoir où trouver les résultats. Des outils de construction communs, afin que votre build donne le même résultat que le mien. Des bibliothèques standardisées, pour que lors du remplacement d’un composant, vous n’ayez pas à chercher quelles versions fonctionnent pour vous mais pas pour moi. Des revues de code standardisées et une transparence du dépôt de code, afin de savoir quel code doit être modifié. Les changements à grande échelle sont l’expression ultime de la philosophie de Google selon laquelle « l’automatisation prime sur le travail manuel », et ils ne sont possibles que si tout l’écosystème collabore. Vous ne pouvez pas pointer sur une seule partie de l’environnement de développement et dire : « C’est là que ça vient », car c’est l’ensemble des parties interconnectées qui en est la cause.

Votre écosystème, vos compromis

Chaque écosystème de développeurs possède de telles propriétés émergentes. Ce sont généralement ces éléments qui donnent à votre lieu de travail un caractère unique, car ils sont le résultat d’une série de choix que vous avez faits.

L'écosystème de développeurs de Google a engendré un ensemble d'équilibres uniques qui servent nos objectifs techniques et commerciaux. Mais comme tout écosystème, il ne peut exceller dans toutes les tâches. Nous avons choisi d'optimiser l'échelle extrême, la sécurité et les performances, même si cela signifie parfois sacrifier la productivité des développeurs — nous acceptons ce compromis. Un écosystème pour une startup de cinq personnes serait radicalement différent, où la vitesse et l'agilité seraient primordiales.

La plupart d’entre vous se trouvent dans un écosystème compris entre cinq personnes et deux cent mille personnes. Les compromis que vous devez faire méritent une attention particulière, car en examinant ces compromis, vous pouvez commencer à comprendre les valeurs de l’organisation : ce qu’elle prend vraiment à cœur, et non ce qu’elle prétend prendre à cœur, mais ce que révèlent les choix que vous observez concrètement. Une fois que vous comprenez ces valeurs, vous pouvez commencer à façonner la transformation en cours.

Moment à 10x : chaque nœud est sous pression

Il est temps de parler de l’éléphant dans la pièce qui mange des tokens : à quoi ressemble un écosystème de développeurs orienté IA ?

Construire entièrement un nouvel écosystème à partir de zéro serait idéal, mais personne n’a ce luxe. Vous devez continuer à livrer du logiciel tout en remplaçant presque chaque composant. L’entreprise compte sur vous pour continuer à créer de la valeur tout en garantissant qu’aucun problème ne survienne.

Posez-vous alors cette question : à quel point connaissez-vous votre écosystème de développeurs aujourd’hui ? Pouvez-vous le dessiner entièrement ? Connaissez-vous l’emplacement de tous les composants, pas seulement techniques, mais aussi sociaux ? Pouvez-vous énumérer ce qui constitue votre écosystème ? Vos collègues au sein de votre organisation en savent-ils autant ? Quels sont ses avantages et ses inconvénients ? Où se trouvent les goulets d’étranglement ? Où les contraintes s’appliquent-elles, et où réside la liberté ? Quelles sont vos options ? Quels types de propriétés émergentes avez-vous observés ? Peut-être la question la plus cruciale : si votre écosystème devait soudainement traiter 10 à 15 fois plus de code dans les dix-huit prochains mois, savez-vous ce qui céderait en premier ?

Chaque écosystème de développeurs sur Terre traverse une transformation radicale ; peut-être n’a-t-elle pas encore atteint chaque recoin de votre région, mais elle arrive, et chaque écosystème de développeurs devra faire face à ce moment de multiplication par dix. C’est une époque incroyable, mais aussi assez confuse. Les compromis que nous avons délibérément cultivés au cours des vingt-cinq dernières années seront rééquilibrés.

Générer du code 10 fois plus vite et accélérer le développement ingénierie de 10 fois, ce sont deux choses différentes. Chez Google, nous disons souvent que l'ingénierie est la programmation intégrée dans le temps. Mais le problème est que nous accélérons considérablement la phase de programmation, en faisant fonctionner la machine à code à grande vitesse. Nous devons donc trouver des moyens de bien structurer l'ingénierie autour de cette machine à code, afin de livrer réellement des résultats aux clients. Personne ne sait jusqu’où cette augmentation de productivité nous mènera, mais une chose est certaine : nous partons d’ici vers le haut.

Le problème, c’est que la manière dont nous construisons et livrons des logiciels aujourd’hui ne fonctionnera pas à une vitesse 10 ou 100 fois supérieure ; quelque chose doit changer.

Commençons par examiner une version simplifiée du schéma de l'écosystème de développeurs. Dans un monde où l'activité augmente de dix fois, qu'est-ce qui doit changer ?

Code mis en dépôt

Écrivez du code source. Si tout le monde écrit du code beaucoup plus rapidement, la quantité de code augmentera considérablement, ce qui n'est pas une bonne chose. Jeff Atwood a dit que le logiciel est une dette. Ainsi, dix fois plus de code, dix fois plus de dette. Et vous ne pouvez pas simplement distribuer des jetons à tout le monde en disant « Bonne chance » ; j'espère que vous investirez après avoir été formé : savez-vous où se trouvent vos documents sur les pratiques d'ingénierie ? Savez-vous comment les faire évoluer ? Envisagez-le ensuite.

Construire un système. Plus de code, un système plus grand signifie des temps de compilation plus longs. Je suis sûr que personne dans votre entreprise ne se plaint actuellement de la lenteur de la compilation. Mais devinez quoi, elle deviendra encore plus lente. Et si l’agent pilote une quantité massive de travail, le nombre de compilations explose. La compilation n’est pas gratuite, ni en temps ni en ressources informatiques. Vous n’avez peut-être jamais prêté attention au temps que vous passez à compiler, mais à une échelle 10 fois plus grande, vous le remarquerez certainement.

Conception du code. Disposez-vous de compétences adaptées en agent pour encourager le découplage ? Disposez-vous d’un cadre serveur approprié pour garantir la combinaison rapide et sécurisée de diverses capacités ? Savez-vous combien de méthodes de déploiement existent pour les applications web au sein de votre entreprise ? Combien de cadres serveur différents sont en cours d’utilisation ? Comment gérez-vous la réutilisation des composants du code écrit par les agents ? Peut-être pariez-vous que cela n’a pas d’importance. Mais si les agents produisent du code facile à écrire mais difficile à maintenir, ne soyez pas surpris : c’est le niveau de référence actuel. Les agents sont excellents pour écrire du code, mais ne réfléchissent pas toujours à long terme. Ce code-là, je suis sûr qu’il ne sera pas facilement重构. Ce n’est pas grave, nous réglerons cette partie plus tard. Mais le fait est que les agents accomplissent pour nous une grande partie du travail, et nous devons chaque jour trouver les moyens les plus efficaces d’exploiter ces capacités.

À un moment donné, ces travaux basés sur des agents pourraient rendre vos fichiers binaires trop volumineux pour être compilés, ou trop gros pour être transférés sur un téléphone. Vous êtes-vous déjà posé cette question : quelle est la taille maximale d’un binaire que vous pouvez compiler ? Je ne connais pas la réponse, mais je sais qu’à Google, nous atteignons les limites, et certains binaires sont déjà trop volumineux pour être compilés. Je crois que nous trouverons une solution. Mais le fait est que l’échelle engendre de nombreuses répercussions ; les effets de la taille sont partout.

Peut-être que vous utilisez une pile de microservices et que vous pensez : « Mes services sont tous petits, pourquoi m'en inquiéter ? » Mais j'ai une question : 10 fois le trafic réseau, 10 fois le nombre de services, 10 fois le volume de communication — êtes-vous prêt ? Personne ne peut en sortir indemne ; les effets de l'échelle sont partout.

Revue de code. Supposons que vous ne puissiez pas compiler de manière fiable tout ce code, comment votre processus de revue de code évoluerait-il ? Tout le monde s'inquiète de la revue de code, et à juste titre. Nous exerçons une pression énorme sur ce processus profondément humain, qui, dans de nombreux cas, devient un goulot d'étranglement — et les gens n'aiment pas être un goulot d'étranglement. Lorsque vous les mettez sous pression, leur comportement devient étrange. Dix fois plus de code, c'est soit dix fois des modifications plus volumineuses, soit dix fois plus de modifications. Votre chef technique peut-il maintenir la vitesse de revue nécessaire ? La plupart des chefs techniques ne parviennent même pas à reviser le code produit en une journée par cinq développeurs à dix fois leur productivité.

Ainsi, pour ne pas devenir un goulot d'étranglement, ils commenceront à réorganiser les processus, à prendre des raccourcis et à s'assurer de ne bloquer personne, car personne ne veut être celui qui bloque. Vous pourriez peut-être résoudre une partie du problème avec l'IA, en déployant des outils d'IA pour améliorer les revues de code. Mais cela ne résout qu'une partie du problème, car si vos membres d'équipe ne écrivent plus de code, le seul moment où ils rencontrent du code est lors des revues, et si l'attention portée lors de ces revues est insuffisante, qui suit l'évolution de la base de code ? Personne. Très rapidement, votre base de code deviendra un désordre incompréhensible pour tout le monde.

Économie des jetons. Les jetons sont chers, certains d'entre vous le savent déjà. À grande échelle, le jeton représente un coût réel que vous devez prendre en compte. Que se passerait-il si chacun dans l'entreprise commençait à utiliser 10 ou 100 fois plus de jetons ? Et si vous dépensiez accidentellement tout votre budget mensuel en une seule journée ? Si vous devez prioriser où utiliser vos jetons, savez-vous où investir en priorité ? Avez-vous même une visibilité sur l'endroit où les jetons sont effectivement dirigés ?

Dans les premiers nœuds de ce système simple uniquement, nous avons déjà identifié des problèmes. Et il est très clair qu'il y aura certains effets de second ordre complexes.

Test et contrôle de version

Avez-vous déjà observé la quantité de ressources de calcul consommées par votre infrastructure de test ? Chez Google, je n’ai jamais été satisfait de la vitesse de mes tests.

Chaque modification soumise au contrôle de version doit être testée. Mais en plus, les agents aiment également exécuter les tests, car ceux-ci leur indiquent s'ils font bien leur travail. Ainsi, les agents génèrent un travail supplémentaire, ce qui augmente ma charge de travail. Alors, avec dix fois plus de commits et tout le travail effectué par les agents, combien de ressources de calcul pour les tests sont désormais consommées ?

En réalité, la situation pourrait être encore pire. Nous avons observé sur Google que, à mesure que la base de code croît, le graphe de dépendances augmente de manière quadratique, et non linéaire. Ainsi, si votre base de code est 10 fois plus grande, vous pourriez devoir exécuter non pas 10 fois plus de tests, mais 100 ou même 1000 fois plus. Ce sera un défi très intéressant, et à un moment donné, cela deviendra une ligne sur votre budget. Si vous ne vous inquiétez pas maintenant du coût des ressources de calcul pour les tests, c’est cela qui me préoccupe davantage, car cela signifie que vous n’avez probablement pas suffisamment de tests, et que vos agents évoluent dans votre base de code sans filet de sécurité.

Supposons que la compilation et les tests soient résolus, passons maintenant au système de contrôle de version. La plupart des systèmes de contrôle de version populaires ne sont pas optimisés pour les performances ; ils sont optimisés pour la cohérence et l'ordre. C'est leur métier : maintenir un historique complet, pas courir à toute vitesse. Combien de commits votre système de contrôle de version peut-il traiter par minute ? Je vous garantis qu'il en traite bien moins que vous ne le pensez. Il ne peut pas s'échelonner jusqu'à la vitesse 10 fois plus rapide dont vous avez besoin. Quand avez-vous pour la dernière fois pensé aux performances de votre système de contrôle de version ? Si vous ne développez pas Git, vous n'y avez probablement jamais pensé. Honnêtement, se retrouver à discuter des performances du contrôle de version signifie que quelque chose s'est sérieusement déréglé. Nous sommes au plus bas niveau de l'expérience développeur, mais c'est précisément la conséquence des changements systémiques : ils trouvent chaque recoin de votre système et disent : « Hé, tu fais attention ? » parce que quelque chose que tu n'as pas anticipé arrive.

Pour ceux qui pensent résoudre les problèmes de gestion de version en utilisant de nombreux petits dépôts, demandez à quiconque a géré des centaines ou des milliers de petits dépôts : je peux vous garantir que cela crée tout un nouvel ensemble de défis, et l’IA ne rend pas nécessairement ces problèmes plus faciles.

Liste des incidents

Jusqu'à présent, nous n'avons examiné que les nœuds de capacité relativement faciles à identifier, c'est-à-dire multiplier un chiffre par 10 et se demander si cela sera bon ou mauvais, ainsi que de nombreux défis inattendus.

Vérifiez la stratégie. Votre vérification d’aujourd’hui consiste probablement en de nombreux tests unitaires et quelques tests d’intégration. Mais dans un monde où le code et les services sont multipliés par 10, les tests d’intégration deviendront la partie la plus importante de la stratégie de qualité. Combien d’entre vous sont satisfaits de votre approche actuelle des tests d’intégration ? Moi non plus. Les tests d’intégration sont vraiment difficiles ; je n’ai pas encore les outils nécessaires pour les réaliser comme je le voudrais.

Problème de conjonction booléenne. Aujourd'hui, vous publiez un logiciel et vous exigez que chaque test réussisse, que toutes les valeurs booléennes soient vertes, et que tout soit parfait avant la publication — c'est raisonnable. Que se passe-t-il lorsque vous avez un million de tests, et que la fiabilité même de l'infrastructure de test sous-jacente pour exécuter un million de tests est douteuse ? Il devient alors impossible de garantir que toutes les valeurs booléennes soient vraies pour publier le logiciel. Vous avez besoin d'une nouvelle stratégie, probablement basée sur des méthodes statistiques, pour déterminer quels tests sont pertinents à exécuter, car vous ne pouvez pas tous les lancer.

Changement énorme. Il est excitant de pouvoir refactoriser partout, changer de langage et de framework. Mais avez-vous des flux de travail et des contrats sociaux qui permettent aux gens de gérer des conflits de fusion de dizaines de milliers, voire de millions de lignes ? Probablement pas. Si chacun dans l'entreprise pouvait effectuer des changements énormes, nous aurions besoin de nouvelles stratégies de flux de travail.

La guerre des agents. Un agent effectue une modification, un autre agent arrive en disant : « Non, je n’aime pas ça, je vais faire une modification différente. » C’est amusant à regarder, jusqu’au moment où vous réalisez que vous payez des frais de token pour les deux côtés.

Fréquence de déploiement. Combien de fois par jour publies-tu auprès de tes clients ? Chaque jour ? C’est déjà pas mal. Sinon, voici le problème : tu vas accumuler dix fois plus de logiciels, et il faut bien les placer quelque part. Si tu ne publies pas quotidiennement, chaque modification devient beaucoup plus importante. Mes amis SRE te diront que de très grosses modifications sont très effrayantes. Évite cela. Mais le code doit être déployé pour générer de la valeur, donc tu pourrais essayer de publier plus fréquemment — c’est bien, les amis de DORA seront contents. Mais à un moment donné, les gains diminuent : publier une fois par seconde ne t’apportera probablement pas beaucoup de valeur. Le code continuera de croître, et tu devras trouver un moyen de le placer sans augmenter davantage les risques.

API interne. Je n'arrête pas de dire à mes collègues que vos API sont soudainement devenues publiques. L'agent ne vous consultera pas ; il trouvera l'API et l'appellera directement. Il utilisera tout ce qu'il peut accéder, je vous le garantis. Si vous n'avez jamais renforcé vos interfaces internes et vos jeux de données internes comme vous le feriez pour des API publiques, l'agent trouvera ce que vous ne souhaitez pas qu'il trouve.

Le paradoxe de Jevons. Jevons a affirmé que plus une ressource est bon marché et efficace, plus nous en utilisons. L'explosion des tokens en est un exemple vivant. Nous les intégrons partout, ce qui modifie la manière dont nous travaillons et dont nous pensons le travail. Nous sommes en train de donner une valeur à des activités de productivité auparavant invisibles ; quel impact cela aura-t-il sur notre comportement ? Je ne le sais pas encore.

Rollback. Saviez-vous pourquoi le rollback est aujourd'hui fondamentalement faisable ? Parce que vous publiez du logiciel légèrement plus lentement que le temps nécessaire pour détecter un problème dans votre environnement de production. Si vous pouviez publier extrêmement rapidement, au point de ne pas avoir le temps de détecter aucun problème, quelle serait votre posture de rollback ? Chaque rollback devrait alors gérer plusieurs changements superposés et mutuellement contradictoires. Ainsi, publier plus vite ne suffit pas : vous devez considérer l'ensemble du système, y compris le rollback, ce mécanisme de sécurité crucial. Au passage, faites attention à l'endroit où vous placez votre moteur de jetons. Si votre processus de rollback dépend d'un agent ayant suffisamment de capacité, et que quelqu'un a précédemment épuisé le budget de jetons de cet agent, vous empêchant désormais de rollback, ce ne serait probablement pas une bonne chose.

Chacun est un constructeur. Vous avez probablement déjà pensé à créer une alternative au outil que vous n'aimez pas dans votre entreprise. Maintenant, multipliez cela par chaque personne et chaque outil au sein de l'entreprise. Que devient la trame sociale de l'entreprise lorsque chacun utilise des outils complètement différents ? Si vous avez de la chance et qu'une base de données unifiée regroupe toutes les données en un seul endroit, c'est acceptable. Mais sinon ? Être chacun un constructeur est génial… jusqu'au moment où vous devez maintenir tout ce que tout le monde a construit.

Cours intensif de leadership technique. Il faut tant de temps pour devenir un chef technique parce que vous devez acquérir de l’intuition, du jugement et des compétences professionnelles pour prendre des décisions, car lorsque vous dirigez une équipe, vos erreurs ont un impact bien plus large que si vous agissiez seul. Que se passe-t-il lorsqu’un jeune diplômé entre dans un environnement où il peut appeler cinquante agents, sans aucune intuition ni jugement ? Comment puis-je enseigner dix ans d’expérience en six mois ? Je n’en sais rien.

L'attention humaine est notre ressource la plus précieuse. Il y a aujourd'hui un bruit excessif, de nombreux agents et de nombreuses choses qui rivalisent pour notre attention, et nous devons trouver des moyens de la gérer. Autrefois, nous profitions du fait que notre capacité à créer des problèmes ne dépassait pas notre capacité à accorder notre attention, mais ce n'est plus le cas aujourd'hui.

Cela semble beaucoup, car dans un système, tout est interconnecté. Tous les défis que j'ai mentionnés précédemment ne peuvent être résolus en observant simplement un nœud du système ; vous devez examiner l'ensemble du système.

Pour s'adapter au développement basé sur des agents, nous devons tous apprendre à penser de manière systémique et continue. Lorsque vous réfléchissez à un système, voici les éléments à surveiller : la croissance des éléments, les effets évoluant dans le temps, la direction des relations de cause à effet, quels nœuds communiquent avec tous leurs voisins, à quoi ressemble l'émergence, et ce que sont ces éléments qui apparaissent sans explication apparente. Quels sont les mécanismes d'incitation — sociaux et techniques — ainsi que les capacités, les boucles de rétroaction et les goulets d'étranglement ? Ce sont là les outils de l'analyse systémique.

Cela semble complexe, mais vous n'avez en réalité besoin que de deux questions : pourquoi (Why ?), et et si (What if ?). Pourquoi avons-nous si peu de tests d'intégration ? Et si nous avions plus de tests d'intégration que de tests unitaires ? Pourquoi utilisons-nous ces langages spécifiques ? Et si l'IA écrivait tout le code ?

« Pourquoi » est le foret que vous utilisez pour pénétrer au cœur du système et comprendre comment il fonctionne. Vous êtes tous très doués pour poser des « pourquoi », mais le « et si » est la partie plus difficile. Le « et si » peut être effrayant, surtout s’il vous oblige à abandonner des pratiques que vous croyiez autrefois parfaitement conçues. Et si vous ne testiez pas ? Et si vous n’écriviez pas du tout de tests ? Ne poussez pas trop loin. Mais si vous permettez que cela se produise, le « et si » peut aussi être assez excitant.

L'IA est un amplificateur, pas une direction

L'IA est un amplificateur. Cette idée provient de mes amis chez DORA, dont le rapport sur le développement de l'IA l'année dernière a révélé une corrélation entre les équipes qui ont vraiment compris les choses : elles ont appris à faire de l'IA un amplificateur.

L'IA peut vous donner plus. Plus de tests, plus de documentation, plus de code, mais aussi plus de désordre. L'amplification concerne l'amplitude, pas la direction. L'IA ne se soucie pas de l'endroit où vont ces éléments ; elle vous en donne simplement plus. Ce que DORA a réellement découvert, c'est que les équipes ayant une solide base peuvent orienter cet effet d'amplification vers des directions utiles.

Cela soulève la question : comment vous sentez-vous concernant vos fondamentaux ? Quelle est la culture décisionnelle de votre entreprise ? Que pouvez-vous faire pour l'améliorer ? Et la stratégie technique ? Quelqu'un s'intéresse-t-il à la productivité des développeurs ? Comment les personnes au sein de l'organisation collaborent-elles aujourd'hui ? Quelle est la posture de sécurité ? Et la santé du code, l'hygiène des déploiements, la fiabilité ? L'IA ne résout pas automatiquement vos problèmes. Si vos pratiques sont bonnes, elle les amplifie. Mais si elles ne le sont pas, elle ne fait que créer davantage de problèmes.

Mais même avec de solides bases, nous sommes sur le point de vivre un véritable voyage. Je suppose qu’en 2030, notre écosystème de développeurs d’aujourd’hui nous semblera aussi lointain que celui de 2001 nous semble aujourd’hui. En 2001, nous distribuions encore des logiciels sur CD-ROM ; en 2030, nous pourrions être aussi éloignés de cette époque.

Pendant que vous continuez à renforcer vos bases, voici quatre choses à avoir en tête en chemin.

Premièrement, la capacité des infrastructures. Si vous ne savez pas combien de ressources vous avez à disposition, vous ne pouvez pas déployer d'IA ni de ressources de calcul ; vous avez besoin d'une bonne méthode pour suivre ces éléments.

Deuxièmement, validez votre stratégie. Vous ne pouvez ni ne devez publier de logiciel non validé. Mais les stratégies de validation évoluent ; il est temps d’y réfléchir sérieusement. Les tests d’intégration deviendront votre arme la plus importante, et vous n’avez peut-être pas encore les outils adaptés.

Troisièmement, l'isolation. Vous obtiendrez beaucoup de code destiné à des fins différentes, certaines n'ayant jamais été traitées par du code auparavant. Cela ne pose pas problème, mais vous ne voulez pas qu'un prototype amusant se retrouve réellement en production. Gardez les choses ludiques loin des activités génératrices de revenus.

Quatrièmement, l'abstraction. Nous créons des abstractions pour empêcher les développeurs de prendre de mauvaises décisions, c'est pourquoi nous avons des bibliothèques et des frameworks. Personne ne réécrit un serveur web depuis zéro. Permettre à un agent de prendre un grand nombre de décisions conduit aux mêmes conséquences, vous avez donc besoin de bonnes abstractions que l'agent peut suivre. Ne lui offrez pas de mauvais choix.

Vous devez aussi accepter une chose : les pratiques d’ingénierie ne sont pas sacrées. Les pratiques évoluent, ce sont les principes qui comptent. Cela semble simple à dire, mais difficile à faire : si vous n’avez jamais vraiment réfléchi à pourquoi votre équipe teste le logiciel de cette manière, ou pourquoi le processus de publication fonctionne ainsi, vous ne pourrez pas l’évoluer. Comprendre les principes vous donnera la force et la confiance nécessaires pour traverser ce moment de multiplication par 10.

C’est une époque fascinante pour les ingénieurs logiciels. Chaque dimension de notre travail est en train d’être redéfinie ; nous avons plus que jamais besoin de faire preuve de créativité ; nous devons acquérir des compétences pour faire face à des problèmes tels que la gestion du contexte, l’économie des jetons et la dérive des modèles ; nous avons besoin de créativité ; nous ne devons pas nous laisser trop séduire par la tentation d’optimiser tout, et nous devons encourager l’exploration.

Une question me tourmente depuis toujours et qu’aucune optimisation ne peut résoudre : comment maintenir un contrôle intellectuel sur notre codebase à mesure qu’elle grandit ? Le contrôle intellectuel signifie que les humains peuvent-ils raisonner sur ce qui est devant eux ? Nous avons perdu cette bataille depuis au moins quinze ans ; nos systèmes les plus importants dépassent largement la capacité de compréhension d’une seule personne. Si vous n’y croyez pas, faites une expérience : demandez à chaque membre de votre équipe de dessiner un schéma d’architecture du système, et voyez combien de versions différentes vous obtiendrez.

Beaucoup de nos systèmes logiciels sont très fragiles : une seule ligne de code défectueuse ou un indicateur de configuration erroné peut détruire un système de plusieurs centaines de milliers de lignes, ce qui vous oblige à bien réfléchir avant d’apporter des modifications. Mais j’ai une idée très enthousiasmante concernant l’IA : un espace d’architecture en constante mise à jour, presque interactif, auquel je pourrais poser des questions. Que se passerait-il si nous déplacions cette capacité sur la côte est ? Et si la croissance des utilisateurs augmentait soudainement de 40 % ? Pour un système de taille moyenne aujourd’hui, cela serait pratiquement impossible sur le plan fonctionnel, tant les variables sont nombreuses. Mais l’IA peut comprendre des ensembles de données extrêmement volumineux, donc je pense qu’il y a là quelque chose à exploiter.

J'aime cette question parce que nous ne nous concentrons pas uniquement sur le fait de faire tourner les machines plus vite ; nous nous demandons : comment approfondir notre compréhension de ce que nous avons déjà construit ?

Les changements se produisent extrêmement vite, plus rapidement que ce que la plupart d’entre vous ont connu. L’une des choses les plus importantes que vous puissiez faire maintenant, c’est d’aider ceux qui luttent et d’offrir votre soutien à ceux qui n’ont pas encore tout compris. Nous progressons tous à des rythmes différents et faisons face à ce changement de manières variées. Il est facile de se sentir en retard.

Les ingénieurs expérimentés, devenez des mentors. Identifiez les personnes bloquées et aidez-les. Si vous avez déjà compris le flux de travail du développement IA, partagez-le avec les autres ; ce n’est pas un secret précieux. Les responsables techniques, vous devez vous impliquer et aider à guider la direction de l’ingénierie logicielle au sein de votre entreprise. Si vous vous souciez de la qualité logicielle ou de la conception logicielle, vous devez faire entendre votre voix pour la défendre. Ce sont vous, ici présents, qui devez accomplir cela ; votre patron ne le fera probablement pas.

Si nous imaginons l'écosystème des développeurs comme un écosystème vivant, nous avons tous l'habitude de surveiller attentivement chaque feuille sur chaque branche, en prenant soin de chaque arbre comme s'il s'agissait d'une forme de vie particulière. Mais bientôt, il ne s'agira plus d'une seule arbre, mais de toute la forêt. Et vous ne pouvez pas gérer une forêt en observant uniquement un seul arbre ; vous devez voir la forêt comme un écosystème et la gérer en conséquence.

Les changements systémiques ont une caractéristique : ils se produisent simultanément partout et dans tout, d'une ampleur telle qu'il semble impossible de saisir quoi que ce soit. En ce moment même, vous pourriez avoir l'impression que rien ne vous permet de vous tenir fermement face aux vagues de réformes qui arrivent presque chaque semaine. Mais, comme nous venons de le découvrir, dans un système, tout est interconnecté : de petites actions peuvent engendrer de grands effets.

Quelle que soit l'apparence superficielle, la transformation par l'IA n'est pas réservée aux dirigeants d'entreprise. En tant qu'ingénieur logiciel sur le terrain, à ce moment critique, vous êtes au cœur de la détermination de l'avenir du génie logiciel. Des outils aux flux de travail, des pratiques d'ingénierie à la culture d'ingénierie, si vous comprenez les systèmes en marche, vous trouverez des leviers. Vous avez plus d'autonomie que vous ne le pensez — utilisez-la pour créer l'avenir de votre organisation, de votre équipe et de vous-même.