Sarang Kulkarni : les enseignements du développement d'agents de recherche approfondie en production

Des agents en essaim : présentation d'une approche ludique et rentable

Adrian Cockcroft, ancien architecte en chef d'Amazon Web Services et figure reconnue de l'ingénierie cloud, a présenté une conférence intitulée « Diriger un essaim d'agents pour le plaisir et le profit », dans laquelle il expose sa vision de ce qu'il appelle le développement « AI-native ». S'appuyant sur des expériences concrètes menées avec des outils comme Cursor et Claude Flow, il décrit une approche de niveau « directeur » : plutôt que d'écrire du code ligne par ligne, l'ingénieur orchestre des essaims d'agents autonomes qui exécutent les tâches en parallèle. Ses expérimentations couvrent notamment le BDD (développement piloté par le comportement), les serveurs MCP et le portage de code entre langages de programmation. Cette transition du cloud-native vers l'AI-native représente un changement de paradigme majeur pour l'industrie du logiciel. Elle implique que la valeur ajoutée de l'ingénieur se déplace de l'écriture du code vers la conception de plateformes capables de coordonner des agents IA. Pour les équipes de développement, cela signifie repenser les workflows, les outils de revue et la façon dont on mesure la productivité. Cockcroft est l'une des voix les plus influentes à théoriser ce basculement, après avoir contribué à populariser les microservices et l'architecture cloud à grande échelle chez Netflix puis AWS. L'émergence d'outils comme Claude Flow ou les serveurs MCP d'Anthropic crée l'infrastructure nécessaire à cette orchestration multi-agents. La question qui s'ouvre désormais est de savoir quelles compétences humaines resteront irremplaçables dans un pipeline où les agents gèrent l'essentiel de l'exécution technique.

Le développement piloté par les spécifications s'impose pour le code agentique en entreprise

Le développement logiciel piloté par les spécifications s'impose comme la méthode de référence pour déployer des agents de codage autonomes à l'échelle des grandes entreprises. Amazon Web Services en est l'exemple le plus documenté : l'équipe derrière le nouvel environnement de développement Kiro IDE a utilisé Kiro pour construire Kiro lui-même, réduisant les cycles de développement de deux semaines à deux jours. Une équipe d'ingénieurs AWS a mené à bien un projet de refonte architecturale initialement prévu sur dix-huit mois avec trente développeurs, en six personnes en soixante-seize jours. Chez Amazon.com, la fonctionnalité "Add to Delivery", qui permet aux acheteurs d'ajouter des articles après validation de leur commande, a été livrée deux mois avant le calendrier prévu grâce à cette approche. Alexa+, Amazon Finance, Amazon Stores, Fire TV, Last Mile Delivery et Prime Video intègrent désormais tous le développement piloté par les spécifications dans leurs méthodes de production. Ce qui rend cette méthode structurante, c'est qu'elle résout le problème de confiance fondamental posé par le code généré par l'IA. Un agent qui produit cent cinquante commits par semaine dépasse largement la capacité de relecture humaine : aucune équipe ne peut valider manuellement ce volume. La spec devient alors un moteur de vérification automatique. Rédigée avant qu'une seule ligne de code soit écrite, elle définit ce que le système doit faire, ses propriétés attendues et ce que "correct" signifie concrètement. À partir de cette base, des techniques de test basées sur les propriétés et de l'IA neurosymbolique génèrent automatiquement des centaines de cas de test dérivés directement de la spécification, couvrant des cas limites qu'aucun développeur n'aurait envisagé. L'agent peut ainsi se corriger en boucle, en réinjectant les échecs de build et de test dans son propre raisonnement, jusqu'à produire un code à la fois fonctionnel et vérifiable. Cette évolution s'inscrit dans une transformation plus large du secteur. Il y a un an, le "vibe coding" avait popularisé l'idée que n'importe qui pouvait produire du code avec l'IA, au prix d'une qualité souvent médiocre. Le développement piloté par les spécifications répond à la question suivante : comment faire confiance à ce code à grande échelle ? Les équipes qui adoptent cette méthode ne traitent plus l'IA comme un outil ponctuellement consulté, mais comme un agent autonome ancré à une source de vérité permanente. La prochaine étape annoncée est celle d'agents capables de rédiger leurs propres spécifications, utilisant la spec comme mécanisme d'autocorrection et de vérification. Les entreprises qui maîtriseront ce modèle prendront une avance structurelle significative sur celles qui continuent à coder sans cadre formel.

Présentation : accélérer la productivité des développeurs grâce aux LLM chez Zoox

Zoox, filiale autonome d'Amazon spécialisée dans les véhicules sans conducteur, a présenté les détails de "Cortex", sa plateforme interne d'intelligence artificielle dédiée à la productivité des développeurs. Amit Navindgi, ingénieur au sein de l'entreprise, a expliqué comment Zoox a construit cet écosystème sécurisé combinant RAG (génération augmentée par récupération), des LLMs multimodaux et des APIs ouvertes aux contributions internes. L'objectif affiché : remplacer une documentation fragmentée et des flux de travail cloisonnés par un système unifié piloté par des agents IA. L'enjeu dépasse la simple automatisation. Il s'agit de faire basculer toute la culture d'ingénierie vers des workflows autonomes, capables de raisonner et d'agir sans intervention humaine à chaque étape. Pour y parvenir, l'équipe a misé sur deux leviers concrets : la désignation d'"AI champions" au sein des équipes pour accélérer l'adoption en interne, et l'organisation de hackathons permettant aux développeurs d'expérimenter directement avec la plateforme. Cette approche bottom-up vise à ancrer l'IA dans les pratiques quotidiennes plutôt que de l'imposer par directive. La démarche de Zoox s'inscrit dans une tendance qui touche l'ensemble de l'industrie tech : la transition des LLMs utilisés comme simples assistants vers des agents capables d'orchestrer des tâches complexes de bout en bout. Dans un secteur aussi exigeant que la conduite autonome, où la fiabilité est critique, sécuriser les accès aux modèles tout en maintenant la confiance des équipes représente un défi structurel. Le modèle Cortex, avec ses APIs ouvertes aux contributions internes, pourrait servir de référence à d'autres entreprises cherchant à industrialiser l'IA sans sacrifier la sécurité ni l'autonomie des développeurs.

Architectures avancées pour le RAG enrichi par graphes : dépasser la recherche vectorielle en production

Le RAG vectoriel standard, qui consiste à découper des documents en fragments, les encoder dans une base vectorielle et récupérer les résultats les plus proches par similarité cosinus, s'impose depuis plusieurs années comme l'architecture de référence pour ancrer les grands modèles de langage dans des données privées. Mais pour des domaines métier fortement interconnectés comme la chaîne d'approvisionnement, la conformité financière ou la détection de fraude, cette approche atteint rapidement ses limites. Elle capture la similarité sémantique mais ignore la structure. Un modèle ne peut pas répondre à la question "Comment le retard sur le composant X va-t-il affecter la livraison Q3 du client Y ?" si la base vectorielle ne "sait" pas que ce composant fait partie de cette livraison. C'est le problème documenté dans cet article par des ingénieurs ayant travaillé sur les systèmes de logging haute performance de Meta et l'infrastructure de données privées chez Cognee. La solution proposée est une architecture hybride dite "Graph RAG", combinant recherche vectorielle et base de données graphe. Concrètement, lors de l'ingestion des documents, un modèle LLM ou un système de reconnaissance d'entités nommées (NER) extrait les entités et les relations pour les stocker dans un graphe Neo4j, les embeddings vectoriels étant conservés comme propriétés des noeuds. À la requête, le système effectue d'abord un scan vectoriel pour identifier des points d'entrée sémantiquement pertinents, puis traverse les relations du graphe pour reconstituer le contexte structurel complet. L'exemple illustratif est parlant: une recherche vectorielle sur "risques de production" récupère bien un article signalant des inondations en Thaïlande ayant arrêté l'usine d'un fournisseur A, mais sans lien explicite vers les usines clientes en aval, le modèle hallucine ou répond "je ne sais pas" alors que l'information est présente dans le système. Avec le graphe, une requête Cypher permet de traverser les dépendances fournisseur vers usine et de remonter l'impact réel. L'article s'inscrit dans une évolution structurelle de l'ingénierie RAG en production. La leçon clé tirée de Meta est que la structure doit être imposée à l'ingestion, pas reconstruite après coup à partir de données désordonnées. Cette approche "Flat RAG vers Graph RAG" répond à une demande croissante des entreprises qui déploient des LLM sur des données opérationnelles complexes, où les réponses incorrectes ont des conséquences business directes. Neo4j est actuellement le principal acteur côté base de données graphe, tandis que des startups comme Cognee cherchent à industrialiser cette couche d'extraction de connaissance. Les prochaines étapes naturelles incluent la mise à l'échelle de l'extraction d'entités en temps réel et l'intégration de ces architectures dans les frameworks d'agents LLM comme LangGraph ou LlamaIndex.

💬 Le problème du RAG vectoriel sur des données métier complexes, tout le monde le voit en prod depuis un moment. Cette architecture Graph RAG, avec Neo4j et une extraction d'entités à l'ingestion, c'est le genre de solution qui demande un vrai effort d'intégration mais qui répond enfin à des cas réels, pas juste des démos de chaîne logistique imaginaire. Reste à voir si ça scale proprement en temps réel, parce que le NER sur de gros volumes, c'est jamais aussi simple que dans les articles.