Google Agent Smith écrit 25% du code Google: ce que les équipes API doivent savoir

EN BREF

L'agent de codage IA interne de Google, Agent Smith, génère désormais plus de 25 % du nouveau code de production de l'entreprise. Contrairement aux outils de complétion automatique comme Copilot, Agent Smith fonctionne de manière asynchrone en arrière-plan, écrivant, testant et itérant sur le code sans interaction humaine. Pour les équipes API, cela soulève des questions concernant la stabilité des contrats, la couverture des tests, la dérive de la documentation et les flux de travail de révision lorsqu'un quart de votre base de code est généré par une machine.

Introduction

Lors d'un appel aux résultats de mars 2026, le PDG de Google, Sundar Pichai, a révélé un chiffre qui a fait marquer une pause à l'ensemble de l'industrie logicielle : le code généré par l'IA représente désormais plus de 25 % du nouveau code produit chez Google.

Ce n'est pas de l'autocomplétion. Ce ne sont pas des suggestions Copilot acceptées par les développeurs. C'est du code qui est déployé en production après avoir été généré par l'IA. L'outil qui le sous-tend, appelé en interne Agent Smith (un clin d'œil à l'antagoniste auto-réplicateur de The Matrix), est devenu si populaire auprès des plus de 180 000 employés de Google que l'entreprise a dû limiter l'accès pour gérer la charge de l'infrastructure.

Agent Smith représente une catégorie différente des outils de codage IA que la plupart des développeurs utilisent aujourd'hui. Là où Copilot et Claude Code assistent en temps réel, Agent Smith travaille en arrière-plan. Les ingénieurs assignent des tâches, s'éloignent et reviennent plus tard pour examiner le travail terminé.

Pour les équipes de développement API, ce passage du code « assisté par l'IA » au code « généré par l'IA » soulève des questions pratiques. Lorsque 25 % de votre base de code est écrite par un agent autonome, comment maintenir la stabilité des contrats API ? Comment vous assurez-vous que les tests couvrent les points de terminaison générés par la machine ? Comment empêchez-vous la documentation de dériver ?

Cet article explique ce que fait Agent Smith, comment il diffère des autres outils de codage IA, et ce à quoi les équipes API devraient se préparer.

Ce que fait Agent Smith

Codage autonome asynchrone

Agent Smith ne reste pas dans votre IDE à attendre que vous tapiez. Il fonctionne de manière asynchrone en arrière-plan. Voici le flux de travail :

1. Un ingénieur décrit une tâche en langage naturel
2. Agent Smith décompose la tâche en sous-tâches
3. Il écrit du code sur plusieurs fichiers
4. Il exécute des tests et itère sur les échecs
5. L'ingénieur examine le travail terminé

Ceci est fondamentalement différent des suggestions en ligne de Copilot ou des sessions interactives de Claude Code. Agent Smith est plus proche d'un développeur junior qui prend un ticket, disparaît quelques heures et revient avec une pull request.

Les ingénieurs peuvent déléguer des tâches et vérifier la progression via la plateforme de chat interne de Google, même depuis des appareils mobiles. L'outil accède automatiquement aux profils des employés et à la documentation pertinente, tirant le contexte de la base de connaissances interne de Google.

Construit sur Gemini et Antigravity

Agent Smith fonctionne sur la famille de modèles Gemini de Google, augmentée de systèmes de récupération qui lui donnent accès à la vaste base de code et à la documentation internes de Google. Il est construit sur Antigravity, la plateforme de codage agentique existante de Google, mais l'étend avec la décomposition et l'exécution autonome des tâches.

L'augmentation par récupération est essentielle. Agent Smith ne génère pas de code de manière isolée. Il recherche dans la base de code interne de Google des modèles similaires, fait référence aux implémentations existantes et suit les conventions de codage internes. Cette connaissance contextuelle est ce qui permet une production de qualité pour 25 % du code.

Ce que signifie « 25 % du nouveau code »

Le chiffre de Pichai a besoin de contexte. « 25 % du nouveau code » fait référence au code qui :

• Est généré par l'IA, pas auto-complété
• Passe la revue de code (les ingénieurs humains examinent toujours le résultat d'Agent Smith)
• Est déployé dans les systèmes de production
• Est mesuré sur l'ensemble de la production d'ingénierie de Google

Cela ne signifie pas que 25 % de la base de code totale de Google est générée par l'IA. Cela signifie que 25 % du nouveau code écrit aujourd'hui provient d'Agent Smith. La distinction est importante car le nouveau code s'ajoute à une base de code existante écrite par des humains. Mais la trajectoire est claire : le pourcentage augmente, et Pichai l'a souligné comme un avantage stratégique.

En quoi Agent Smith diffère des autres outils de codage IA

Le spectre des outils de codage IA

Agent Smith se situe à l'extrémité autonome de ce spectre. La seule étape supplémentaire serait un déploiement entièrement autonome sans examen humain, ce qu'aucun outil majeur ne fait encore (et ne devrait pas faire).

Pourquoi l'asynchrone est important pour les équipes API

Les outils de codage IA en temps réel (Copilot, Claude Code) fonctionnent dans le flux de travail du développeur. Le développeur voit ce que l'IA écrit, comprend le contexte et effectue des corrections sur le moment.

Les agents asynchrones modifient cette dynamique. Lorsque Agent Smith écrit un point de terminaison API, le développeur l'examine après coup. L'examen est séparé du contexte de création. Cela signifie :

• Le développeur peut ne pas comprendre pourquoi l'agent a choisi un format de réponse particulier
• Les modifications du contrat API peuvent ne pas être évidentes lors d'une revue de code standard
• Les artefacts connexes (tests, docs, maquettes) peuvent ne pas avoir été mis à jour
• Des changements cassants pourraient passer inaperçus si le réviseur ne vérifie pas l'impact complet

Ce qui ne va pas quand l'IA écrit votre code API

Dérive du contrat API

Un contrat API est l'accord entre votre service et ses consommateurs : points de terminaison, schémas de requête/réponse, codes d'état, formats d'erreur. Lorsqu'un développeur humain modifie une API, il met généralement à jour la spécification OpenAPI, informe les consommateurs et versionne la modification.

Lorsqu'un agent autonome modifie une API, ces étapes de coordination ne se produisent pas automatiquement. Agent Smith écrit du code qui passe les tests. Mais les tests ne couvrent que ce qui a été écrit précédemment. Si l'agent modifie un schéma de réponse d'une manière qui passe les tests existants mais qui casse les consommateurs en aval, le problème apparaît en production.

Exemple de scénario :

• Agent Smith est chargé d'« Ajouter les préférences utilisateur au point de terminaison de profil »
• Il ajoute un champ preferences à la réponse GET /api/users/{id}
• Les tests existants passent car ils ne vérifient pas l'absence de champs supplémentaires
• Les types TypeScript de l'équipe front-end n'incluent pas les preferences
• Le parsing JSON strict de l'application mobile échoue sur le champ inattendu

Le code est correct. Les tests passent. Le contrat est rompu.

Lacunes dans la couverture des tests

Le code généré par l'IA s'accompagne de tests générés par l'IA, et les agents IA ont tendance à écrire des tests qui valident ce qu'ils ont construit, et non des tests qui protègent contre les régressions. Cela crée un angle mort : les tests confirment que le nouveau comportement fonctionne, mais ils ne confirment pas que le comportement existant est préservé.

Pour les points de terminaison API, cela signifie :

• Les benchmarks de temps de réponse peuvent ne pas être testés
• Les formats de réponse d'erreur peuvent s'écarter de votre schéma d'erreur standard
• Le comportement de limitation de débit peut ne pas être validé
• Les cas limites d'authentification peuvent ne pas être couverts
• Le comportement de pagination peut différer des points de terminaison existants

Dérive de la documentation

Si votre documentation API est générée à partir d'annotations de code ou de spécifications OpenAPI, le code modifié par l'agent devrait se propager automatiquement à la documentation. Mais de nombreuses équipes maintiennent la documentation séparément. Lorsqu'Agent Smith ajoute un point de terminaison ou modifie un schéma de réponse, la mise à jour de la documentation est une tâche distincte que l'agent peut ou non effectuer.

Même avec une documentation auto-générée, les descriptions, exemples et notes d'utilisation nécessitent un contexte humain que l'agent IA n'a pas. L'agent peut documenter ce que fait un point de terminaison. Il ne peut pas documenter pourquoi il existe, qui l'utilise, ou quels compromis ont mené à sa conception.

Fatigue de la révision

Lorsque 25 % du code est généré par l'IA, 25 % des revues de code examinent le résultat de l'IA. Le code généré par l'IA est syntaxiquement cohérent et bien structuré, ce qui le fait paraître « correct » au premier coup d'œil. Mais paraître correct n'est pas la même chose qu'être correct dans le contexte.

Les relecteurs sont confrontés à un nouveau défi : le code se lit bien mais peut ne pas correspondre aux décisions architecturales, aux conventions d'équipe ou aux exigences implicites qui existent dans la tête du relecteur mais pas dans l'instruction de l'agent. Avec le temps, la fatigue de la relecture du code généré par l'IA peut conduire à l'approbation automatique (rubber-stamping), ce qui est le moment où les bugs commencent à être déployés.

Comment construire des flux de travail API à l'épreuve des agents

1. Faire des contrats API la source de vérité

Le développement API axé sur la conception est la défense la plus solide contre la dérive induite par les agents. Lorsque la spécification OpenAPI est la source de vérité, toute modification de code qui rompt le contrat est détectable.

Sans approche "design-first" :

Modification du code → Tests réussis → Déploiement → Contrat rompu

Avec approche "design-first" :

La spécification définit le contrat → Le code doit correspondre à la spécification → La validation du contrat détecte la dérive

Le concepteur d'API visuel d'Apidog vous permet de définir les points de terminaison, les schémas et les formats de réponse avant qu'aucun code ne soit écrit. Lorsque Agent Smith (ou tout autre agent) génère du code, vous le validez par rapport à la spécification, et non par rapport à des tests existants qui pourraient être incomplets.

2. Utiliser les tests de contrat, pas les tests unitaires

Les tests unitaires valident le comportement interne. Les tests de contrat valident l'accord entre les services. Lorsqu'un agent IA modifie votre API, les tests de contrat détectent les changements que les tests unitaires manquent.

Exemple de test de contrat :

// Ce test échoue si la forme de la réponse change,
// même si la nouvelle forme est "valide"
describe("contrat GET /api/users/:id", () => {
  it("retourne le schéma attendu", async () => {
    const response = await request(app).get("/api/users/123");

    expect(response.body).toMatchSchema({
      type: "object",
      required: ["id", "name", "email", "created_at"],
      properties: {
        id: { type: "string" },
        name: { type: "string" },
        email: { type: "string", format: "email" },
        created_at: { type: "string", format: "date-time" }
      },
      additionalProperties: false  // Ceci détecte les champs inattendus
    });
  });
});

La ligne additionalProperties: false est critique. Sans elle, un agent qui ajoute des champs à la réponse passe tous les tests. Avec elle, tout changement de schéma nécessite des mises à jour de contrat explicites.

Apidog automatise les tests de contrat à partir de votre spécification API. Définissez votre schéma une seule fois, et Apidog valide chaque réponse par rapport à celui-ci lors des tests manuels et des exécutions CI/CD.

3. Bloquer les déploiements sur la validation des spécifications

Ajoutez la validation des spécifications API à votre pipeline CI/CD. Avant que tout code (humain ou généré par l'IA) ne soit déployé, vérifiez qu'il correspond au contrat déclaré :

# Étape du pipeline CI/CD
- name: Valider le contrat API
  run: |
    # Comparer la spécification actuelle avec l'implémentation en cours d'exécution
    apidog run --test-scenario-id CONTRACT_TESTS
    
    # Échec si des violations de contrat sont trouvées
    if [ $? -ne 0 ]; then
      echo "Violation du contrat API détectée. Examinez les changements."
      exit 1
    fi

Ceci détecte les modifications d'Agent Smith qui enfreignent le contrat avant qu'elles n'atteignent la production.

4. Exiger des mises à jour de spécification pour les changements d'API

Créez une règle de développement : toute PR qui modifie le comportement de l'API doit inclure une mise à jour correspondante de la spécification OpenAPI. Pour les PR générées par l'IA, cela signifie que l'agent doit mettre à jour la spécification, ou qu'un humain doit le faire avant de fusionner.

Dans Apidog, les changements de spécification se propagent automatiquement à :

• La documentation API
• Les réponses du serveur de maquette
• Les assertions de test
• Les types de SDK client

Cette cascade garantit qu'aucun artefact ne dérive lorsque le contrat change.

5. Surveiller le comportement de l'API en production

Même avec les tests de contrat et la validation des spécifications, la surveillance en production détecte ce que les tests de pré-production manquent. Suivez :

• Violations du schéma de réponse : Enregistrez lorsque les réponses ne correspondent pas au schéma déclaré
• Apparition de nouveaux champs : Alertez sur les champs de réponse qui ne sont pas dans la spécification
• Changements du taux d'erreur : Les points de terminaison générés par l'IA peuvent avoir des distributions d'erreurs différentes
• Changements de latence : Le code écrit par l'agent peut avoir des caractéristiques de performance différentes
• Changements de modèle de trafic : Les nouveaux points de terminaison peuvent recevoir des modèles de trafic inattendus

6. Séparer la revue d'API de la revue de code

La revue de code standard demande : « Ce code fonctionne-t-il ? » La revue d'API demande : « Ce changement affecte-t-il les consommateurs ? »

Pour les changements d'API générés par l'IA, créez une liste de contrôle de révision distincte :

• Ce changement casse-t-il un consommateur existant ?
• La spécification OpenAPI est-elle mise à jour ?
• Les changements rétrocompatibles sont-ils versionnés ?
• Les réponses d'erreur sont-elles cohérentes avec le format d'erreur existant ?
• Les nouveaux points de terminaison sont-ils documentés avec des exemples ?
• Les équipes en aval ont-elles été informées ?

La trajectoire : où va le codage autonome

Agent Smith aujourd'hui vs. demain

Agent Smith à 25 % est le point de départ. Sergey Brin a qualifié les agents IA de « grand axe » lors d'une réunion commerciale en mars 2026. Le chiffre de 25 % augmentera à mesure que l'outil s'améliorera, que les restrictions d'accès s'assoupliront et que les flux de travail s'adapteront.

D'autres entreprises construisent des systèmes similaires :

• KAIROS de Claude Code (fuite dans le code source) : démon toujours actif avec abonnements aux webhooks GitHub et workers en arrière-plan
• Mode Agent de GitHub Copilot : tâches de codage multi-étapes avec édition de fichiers autonome
• CodeWhisperer d'Amazon : passant de l'autocomplétion vers des flux de travail agentiques

La tendance de l'industrie est claire : les outils de codage IA passent de « l'assistant » au « contributeur autonome » à « l'infrastructure d'arrière-plan ». D'ici quelques années, la question ne sera plus de savoir si l'IA écrit votre code API, mais quelle part de celui-ci.

Ce à quoi les équipes API devraient se préparer maintenant

L'approche "design-first" n'est plus facultative. Lorsque les agents écrivent du code, la spécification API est le seul artefact stable. Faites-en la source de vérité dès maintenant, avant que l'adoption des agents ne la rende urgente.

Investissez dans une infrastructure de tests de contrat. Les tests unitaires ne suffisent pas lorsque l'auteur du code ne comprend pas vos conventions non écrites. Les tests de contrat encodent ces conventions explicitement.

Choisissez des outils qui maintiennent les artefacts synchronisés. Les outils déconnectés (client API séparé, exécuteur de tests séparé, serveur de maquette séparé, générateur de documentation séparé) créent des opportunités de dérive que les agents exploitent. Les plateformes intégrées comme Apidog maintiennent tout synchronisé.

Mettez en place des processus de révision pour le code généré par l'IA. Une revue de code standard ne détecte pas les violations de contrat API. Créez des listes de contrôle et une validation automatisée spécifiquement pour les changements d'API.

Essayez Apidog gratuitement pour construire des flux de travail API qui restent cohérents, que votre prochaine modification de code provienne d'un développeur humain, d'Agent Smith ou de tout autre outil de codage autonome à venir.

FAQ

Qu'est-ce que Google Agent Smith ?

Agent Smith est l'agent de codage IA interne de Google, construit sur la famille de modèles Gemini et la plateforme Antigravity. Il fonctionne de manière asynchrone en arrière-plan : les ingénieurs assignent des tâches, et Agent Smith écrit, teste et itère sur le code sans interaction humaine en temps réel. Il a généré plus de 25 % du nouveau code de production de Google en mars 2026.

Agent Smith est-il disponible en dehors de Google ?

Non. Agent Smith est un outil interne restreint aux employés de Google. Google n'a pas annoncé de plans de sortie publique. La technologie est similaire au mode Agent de Copilot et à Claude Code, mais elle est plus profondément intégrée aux systèmes de base de code et de documentation internes de Google.

Le code généré par l'IA rompt-il les contrats API ?

Oui, cela peut arriver. Les agents IA écrivent du code qui passe les tests, mais les tests peuvent ne pas couvrir tous les aspects de votre contrat API. Les changements de schéma, les nouveaux champs de réponse, les différents formats d'erreur et les modifications comportementales peuvent échapper aux tests tout en cassant les consommateurs en aval. Les tests de contrat et le développement axé sur la conception empêchent cela.

Les équipes API devraient-elles s'inquiéter d'Agent Smith ?

Pas spécifiquement à propos d'Agent Smith, car il est interne à Google. Mais oui, à propos de la tendance qu'il représente. Des outils de codage autonome similaires (mode Agent de Copilot, KAIROS et autres) arriveront dans votre équipe. Préparer votre flux de travail API dès maintenant, avec le développement axé sur la conception, les tests de contrat et des outils intégrés, vous positionne pour adopter les agents autonomes en toute sécurité.

Comment empêcher les agents IA de casser mes API ?

Utilisez le développement axé sur la conception avec la spécification OpenAPI comme source de vérité. Ajoutez des tests de contrat avec additionalProperties: false pour détecter les changements de schéma inattendus. Bloquez les déploiements sur la validation des spécifications. Utilisez une plateforme intégrée comme Apidog qui synchronise automatiquement les spécifications, les tests, les maquettes et la documentation.

Quelle est la différence entre le code assisté par l'IA et le code généré par l'IA ?

Le code assisté par l'IA (suggestions Copilot, sessions Claude Code) est écrit en temps réel avec une supervision humaine. Le développeur voit et approuve chaque changement. Le code généré par l'IA (Agent Smith) est produit de manière asynchrone sans intervention humaine en temps réel. Le développeur examine le travail terminé après coup. Cette différence modifie la dynamique de révision et augmente le risque de violations de contrat non détectées.

Les agents IA remplaceront-ils les développeurs API ?

Non. Agent Smith nécessite toujours une définition des tâches humaines, une revue de code et une approbation de déploiement. Une étude du MIT de mars 2026 a confirmé que l'IA augmente la productivité des développeurs mais ne remplace pas le jugement, la connaissance du contexte et la pensée architecturale que les humains apportent. Le rôle passe de l'écriture de code à la définition de tâches, à la révision des résultats et au maintien de la cohérence du système.

Points clés à retenir

• Agent Smith de Google génère 25 % du nouveau code de production grâce à un fonctionnement autonome et asynchrone
• Cela représente un passage du code assisté par l'IA au code généré par l'IA, modifiant la dynamique de révision pour les équipes API
• La dérive du contrat API est le risque principal lorsque des agents autonomes modifient les points de terminaison et les schémas
• Le développement axé sur la conception avec les spécifications OpenAPI comme source de vérité prévient la rupture de contrat
• Les tests de contrat avec validation stricte du schéma détectent les changements que les tests unitaires manquent
• Les plateformes intégrées comme Apidog synchronisent les spécifications, les tests, les maquettes et la documentation pour éviter la dérive
• La tendance aux agents de codage autonomes s'accélère ; préparez vos flux de travail API dès maintenant

Agent Smith à 25 % n'est que le début. Les entreprises qui construisent des flux de travail API à l'épreuve des agents aujourd'hui seront celles qui adopteront les outils de codage autonomes en toute sécurité demain.