Andi Gutmans, l’un des contributeurs à la création de PHP 3 et responsable d’Agentic Data Cloud chez Google, ne présente pas le développement logiciel fondé sur les agents comme une rupture totale avec le passé. Lors d’un entretien avec Eira May et Peter O’Connor dans le cadre de l’émission Leaders of Code de Stack Overflow, il a comparé la transformation actuelle à l’impact qu’avait eu PHP en rendant la création de sites accessible à un plus grand nombre de personnes, y compris à celles qui n’étaient pas spécialisées en informatique.
Mais cette nouvelle accessibilité ne signifie pas la disparition de l’expertise technique. Selon Gutmans, le développeur individuel devient progressivement une sorte de « chef d’une équipe d’agents » : il définit les objectifs, répartit le travail, vérifie les résultats et prend les décisions qui ne peuvent pas être déléguées sans limites.
La valeur passe de l’écriture du code au jugement technique
Gutmans estime que certaines questions fondamentales n’ont pas changé avec l’apparition des agents. L’équipe doit toujours s’assurer que la solution répond au bon problème, que l’architecture peut évoluer, et que le système est sécurisé, correctement gouverné, facile à utiliser et adapté en matière de coûts. La nouveauté est que l’agent peut exécuter une plus grande partie du travail de manière autonome ; il faut donc concevoir la manière de le superviser plutôt que de se contenter de réviser le code produit.
Gutmans en a donné un exemple lorsqu’il a utilisé un agent pour créer environ un millier de tests, puis a fait appel à un autre agent pour critiquer ces tests. La révision a révélé que le résultat n’était pas suffisamment bon, et il a dû l’améliorer lui-même. Dans ce cas, le jugement humain n’a pas disparu ; son emplacement a changé : il est passé de l’exécution détaillée à la conception, à la coordination et à l’évaluation.
Cette évolution s’étend également à la compréhension d’une base de code inconnue. Les agents peuvent parcourir une portion plus vaste du projet et découvrir des catégories d’erreurs difficiles à détecter pour un réviseur humain qui n’examine qu’une partie limitée du système. Gutmans a néanmoins déclaré que Google associe la révision humaine à celle des agents, en particulier lorsque les décisions ou les changements sont sensibles.
La révision ne relève pas d’une confiance absolue, mais de la gestion des risques
L’entretien propose d’envisager la supervision selon trois modes : l’humain dans la boucle, l’agent dans la boucle et l’agent au-dessus de la boucle. Il ne s’agit pas de choisir une seule approche valable dans tous les cas, mais de déterminer le niveau de révision approprié en fonction de la probabilité d’erreur et de son impact.
Pour les changements liés à des composants de sécurité sensibles, comme les jetons de sécurité, la participation d’un expert humain est plus importante. En revanche, pour des modifications CSS et HTML ou certains scripts Python, avec l’aide de l’agent pour effectuer un contrôle de sécurité, il peut être pratique de s’appuyer sur un niveau différent d’automatisation. L’idée essentielle n’est pas que les agents ne commettent pas d’erreurs, ni que les humains révisent tout avec une efficacité égale, mais que la décision de réviser doit refléter l’ampleur du risque et ses conséquences.
Gutmans a utilisé l’expérience de Waymo comme exemple pour illustrer l’écart entre le ressenti et les données. Il a déclaré que la probabilité qu’un être humain soit impliqué dans un accident causant des blessures est inférieure de 80 % avec Waymo qu’en prenant place dans un véhicule conduit par un chauffeur Uber, même si beaucoup de personnes se sentent encore plus à l’aise lorsqu’un humain est au volant. De la même manière, une équipe peut refuser l’autonomie d’un agent en raison de son impression, même lorsque les indicateurs montrent que son utilisation pour une tâche donnée pourrait réduire les risques par rapport à l’alternative humaine.
Le recrutement et l’apprentissage s’orientent vers l’évaluation de la capacité à diriger
Gutmans estime que l’enseignement de l’informatique ne s’arrêtera pas, mais que les étudiants pourront réaliser, avec l’aide des agents, des projets plus complexes et de plus grande ampleur. Il restera donc essentiel de savoir concevoir, exploiter et faire évoluer des systèmes, tandis qu’il deviendra également important de savoir formuler un problème, évaluer des solutions et orienter des outils intelligents.
Il a déclaré que Google travaillait à modifier une partie du processus des entretiens techniques. Au lieu de se concentrer sur la demande faite au candidat d’écrire manuellement un algorithme comme quick sort, l’entreprise lui permettra d’utiliser Gemini et l’agent pour résoudre un problème, puis évaluera sa manière de raisonner, la séquence qu’il suit pour traiter la question et la manière dont il oriente l’agent. Cela ne supprime pas les compétences techniques, mais modifie ce que l’entretien cherche à mesurer : la qualité du raisonnement, de la conception et de la coordination plutôt que la rapidité à produire une solution abstraite.
Le principal obstacle pourrait se trouver dans les données, et non dans les modèles
Selon Gutmans, des modèles comme Gemini et Opus sont désormais capables d’automatiser une grande partie des tâches des entreprises ; le principal goulot d’étranglement n’est donc plus constitué par les seuls modèles. Le défi le plus important consiste à rendre les données de l’entreprise compréhensibles et utilisables par les agents, tout en préservant les relations sémantiques, les autorisations et la gouvernance.
Cela comprend les données structurées et opérationnelles, ainsi que les images, les fichiers PDF, les contrats et autres données non structurées présentes dans le stockage cloud ou ailleurs. Google estime que les agents peuvent contribuer à découvrir où se trouvent les données, à comprendre leurs liens réciproques et à construire les représentations sémantiques qui nécessitaient auparavant un grand nombre de gestionnaires de données. Gutmans inscrit cette orientation dans le concept de « borderless lakehouse », qui vise à activer les données indépendamment de leur présence sur GCP, AWS, Azure ou dans des environnements locaux.
Il a également souligné l’importance des formats de données ouverts comme Iceberg, ainsi que le fait que les intégrations intercloud pourraient aider à accéder aux données sans dépendre entièrement des frais de transfert facturés pour chaque gigaoctet. Il a aussi parlé de « knowledge catalog » et du transfert de la construction de l’ontologie, d’un processus entièrement dirigé par les humains vers un processus piloté par les agents, l’humain conservant un rôle de coordination et d’édition plutôt que d’exécution de tâches manuelles lourdes.
Qu’est-ce qui change concrètement ? Pour les équipes techniques, il ne suffit pas de mettre à disposition un agent logiciel et de le laisser travailler. Une utilisation efficace exige de déterminer les tâches qui méritent d’être automatisées, de définir des niveaux de révision adaptés à leurs risques et de vérifier la qualité des données ainsi que les autorisations auxquelles l’agent a accès. Quant au développeur, son rôle ne disparaît pas ; il se rapproche plutôt de celui d’un ingénieur qui dirige un ensemble d’outils capables d’exécuter des tâches et qui assume la responsabilité du jugement final sur ce qu’ils produisent.