Dans cet article
Google a ajouté à son environnement de développement Antigravity une nouvelle commande appelée /boost. Son appel lance un pipeline de raisonnement multi-agents au lieu d'un assistant de programmation unique : un orchestrateur lit le problème et le découpe en tâches, les répartit entre des agents spécialisés qui travaillent dans des périmètres isolés, puis soumet le résultat à des cycles de vérification indépendants qui exécutent réellement les tests avant que quoi que ce soit ne vous parvienne. L'essentiel n'est pas que l'IA écrive du code plus vite. C'est que les outils de programmation ont commencé à intégrer la vérification dans l'outil lui-même.
Ce que Google a réellement annoncé
Selon la documentation officielle d'Antigravity, /boost est conçu spécifiquement pour l'ingénierie logicielle difficile : bogues de concurrence et situations de compétition, optimisation algorithmique, régressions subtiles qui apparaissent et disparaissent, et refactorisations complexes sur plusieurs fichiers. Ce sont exactement les problèmes sur lesquels échoue un assistant classique à tour unique, car les résoudre exige de l'expérimentation et des retours en arrière plutôt qu'une génération directe.
La commande se déroule en trois phases bien distinctes :
- Planification : un orchestrateur principal reçoit votre consigne, examine le contexte de l'espace de travail, élabore une stratégie d'exécution et décompose le défi en sous-tâches distinctes et vérifiables.
- Exécution distribuée : l'orchestrateur répartit ces sous-tâches entre des agents spécialisés. Les flux de mise en œuvre écrivent le code et les tests unitaires. Les flux d'investigation recherchent la cause racine des bogues et tracent les graphes d'appels sans modifier aucun fichier. Des agents de vérification locaux lancent les cibles de compilation et les suites de tests pour valider les hypothèses avant de rendre compte.
- Vérification avant livraison : l'orchestrateur agrège les résultats et lance des contrôles de régression sur les suites de tests complètes et les cas limites. Si une assertion échoue, les diagnostics d'erreur alimentent l'itération suivante pour une correction automatique, et vous ne recevez un résumé des modifications vérifiées qu'une fois que tout passe.
Tout cela s'exécute dans des copies de travail (worktrees) éphémères et isolées : les agents n'expérimentent donc pas sur votre copie de travail du projet.
Trois modes, pas un seul
Google documente trois modes d'exécution distincts, et c'est la différence entre eux qui est utile en pratique :
- Agent par défaut : programmation interactive, navigation dans le code et refactorisation générale. Un horizon de tâche de quelques secondes à quelques minutes, une boucle à agent unique, une vérification en une seule passe. Disponible avec toutes les offres.
- /boost : raisonnement approfondi et bogues tenaces. Un horizon de tâche de quelques secondes à quelques heures, une hiérarchie en trois phases, une vérification indépendante en plusieurs cycles. Disponible avec les offres payantes.
- /teamwork-preview : des équipes d'agents qui travaillent pendant des jours sur de grandes migrations ou la construction de sous-systèmes entiers, avec des rôles nommés comme Explorer, Worker, Critic et Auditor, ainsi que des points de contrôle de vérification qui tentent délibérément de casser le code avant qu'une étape ne soit validée.
Remarquez la gradation : plus la tâche est grande, plus l'investissement porte sur la vérification plutôt que sur la vitesse. C'est un signal qui mérite l'attention de quiconque mène un projet logiciel.
Pourquoi cela compte pour un chef d'entreprise, pas seulement pour un développeur
Depuis deux ans, le débat sur l'IA dans la programmation est un débat sur la vitesse : combien de lignes sont générées par minute. Le problème, c'est que la vitesse n'est pas le goulet d'étranglement des vrais projets. La confiance, si. Ce code fonctionne-t-il vraiment dans les cas que personne n'a essayés ?
Ce que dit implicitement l'architecture de /boost, c'est que le secteur est arrivé à la même conclusion. Un code livré plus vite ne vaut rien s'il coûte deux semaines de débogage après la livraison. L'outil est donc construit autour de trois règles qui s'appliquent à toute équipe technique, avec ou sans IA :
- L'auteur ne note pas son propre travail : la partie qui vérifie est distincte de la partie qui a mis en œuvre. C'est le principe de la relecture de code depuis des décennies. Il est désormais appliqué au sein de l'outil.
- La preuve, c'est l'exécution, pas l'affirmation : les tests sont réellement exécutés et leur sortie réelle est vérifiée, au lieu d'accepter l'affirmation qu'ils ont réussi.
- L'isolement protège l'original : l'expérimentation se fait dans une copie séparée, si bien que les tentatives ratées ne se répandent jamais dans le projet.
Si vous achetez du développement logiciel, ce sont précisément les trois questions à poser à votre fournisseur : qui relit, quelle est la preuve que les tests ont réussi, et où se fait l'expérimentation ?
Ce qui ne change pas
Il est facile de lire ce genre de nouvelle comme l'annonce que les ingénieurs ne sont plus nécessaires. La documentation dit très clairement le contraire : les agents héritent des règles d'accès aux fichiers et des politiques d'autorisation des commandes configurées pour votre espace de travail, et toute commande protégée ou modification hors des périmètres de confiance déclenche une demande d'autorisation auprès de l'utilisateur. Il y a un humain responsable au bout de la chaîne.
Et les autorisations n'en sont que la plus petite moitié. Un agent résout le problème que vous avez décrit. Il ne peut pas savoir que la description elle-même était fausse. Il ne sait pas que votre cycle de facturation se clôture le 25 et non le 30, que tel champ ne doit jamais être visible d'un commercial, ou que lorsque votre client dit « commande », il entend autre chose que vous. Définir les exigences, comprendre le métier et assumer la décision restent un travail entièrement humain.
Notre lecture chez Origami
Nous traitons les outils multi-agents comme n'importe quel outil de productivité : ils accélèrent l'exécution, ils ne transfèrent pas la responsabilité. Chez nous, un projet passe toujours par des spécifications écrites, une relecture humaine, une suite de tests et un environnement de préproduction avant la production, qu'une personne ait écrit le code ou qu'un agent l'ait généré. Un outil qui lance ses propres tests est un ajout bienvenu à cette chaîne, mais il en est un maillon, pas un substitut.
L'enseignement pratique pour un chef d'entreprise : attendez-vous à ce que les délais de livraison se raccourcissent, en particulier sur les travaux complexes, mais n'acceptez pas une livraison sans tests, sans documentation et sans responsable humain. Les outils qui se vérifient eux-mêmes relèvent le plafond de la qualité atteignable. Ils ne suppriment pas votre besoin de quelqu'un qui garantit que ce qui a été construit correspond à ce que vous avez demandé.
Sources
Questions fréquentes
Quelle est la différence entre /boost et un assistant de programmation classique ?
Un assistant classique répond en un seul tour avec un seul agent, ce qui convient au développement de fonctionnalités et à la navigation dans le code. /boost déroule plutôt trois phases : un orchestrateur décompose le problème, des agents spécialisés exécutent le travail dans des périmètres isolés, puis des cycles de vérification indépendants lancent les tests et les contrôles de régression avant la livraison. Il a été conçu spécifiquement pour les bogues difficiles, comme les situations de concurrence et les refactorisations complexes, et selon la documentation de Google, il est disponible avec les offres payantes.
Ce genre d'outil signifie-t-il que je n'ai plus besoin d'une société de développement ?
Non. Un agent met en œuvre ce que vous avez décrit. Il ne peut pas découvrir que la description elle-même était fausse ou incomplète. Définir les exigences, comprendre vos règles métier, vos cycles de facturation et vos droits d'accès, intégrer les systèmes existants et arbitrer entre des besoins contradictoires restent un travail humain. La documentation de Google elle-même précise que les commandes protégées ou les modifications hors des périmètres de confiance exigent l'approbation explicite de l'utilisateur.
Comment savoir si mon fournisseur de logiciels travaille à ce niveau de qualité ?
Posez trois questions précises. Qui relit le code, en dehors de la personne qui l'a écrit ? Existe-t-il une suite de tests qui s'exécute automatiquement avant chaque déploiement, et puis-je en voir les résultats ? Existe-t-il un environnement de préproduction distinct de la production ? Si les réponses sont vagues, le problème ne vient pas des outils utilisés, il vient du processus lui-même.
Mon code ou mes données sont-ils en danger si mon équipe utilise des agents de programmation ?
Le risque dépend de la configuration, pas de l'outil. Vérifiez trois points avant l'adoption : où le code est stocké et qui peut y accéder selon les conditions du fournisseur, quelles autorisations sur les fichiers et les commandes sont accordées à l'agent, et si les secrets et les clés de production sont séparés de l'environnement de développement. Rédiger une politique sur ces points avant l'adoption est bien plus simple que de corriger la situation après coup.
Suivez Origami sur Google
Ajoutez Origami à vos sources préférées : nos articles apparaîtront en premier pour vous dans la recherche Google et les actualités à la une.
