L’essentiel
- OpenAI publie coup sur coup deux témoignages clients sur GPT-6 Astra : Perplexity lui confie l’édition de systèmes réels et la surveillance de sa production, Cognition s’en sert pour faire tester à Devin son propre travail.
- Les deux entreprises visent la même économie : moins de relecture humaine, remplacée par des preuves produites par le modèle, rapport de tests et enregistrement d’exécution.
- Boris Cherny, chez Anthropic, tient la position opposée en interne : le code de production écrit par Claude doit passer une barre plus haute qu’un code humain, avec lint, tests, fuzzers quotidiens et revues automatisées.
Perplexity confie à GPT-6 Astra la rédaction de ses communications, la modification de systèmes réels et la surveillance de ses logiciels en production. Cognition fait tester à Devin son propre travail par le même modèle. Les deux témoignages mettent en avant la même promesse : des heures d’ingénieur libérées.
Un modèle qui fabrique ses propres tests et filme le résultat
Johnny Ho, cofondateur et directeur de la stratégie de Perplexity, décrit un usage très concret. Faute de temps pour tester à la main, il demande au modèle de construire un petit programme de test autour d’une application. Astra fabrique alors des réponses réalistes, celles qu’enverrait une API (interface de programmation) de modèle de langage ou un connecteur. Il se substitue à ces services, puis observe comment l’application réagit sur toute la chaîne.
Sa conclusion est explicite : l’équipe peut faire confiance au modèle sur des systèmes complets et le surveiller beaucoup moins souvent que les générations précédentes. Il ajoute une remarque qui intéresse tout éditeur de moteur de recherche : chaque progrès du modèle en programmation se répercute sur le produit lui-même, qui écrit de meilleurs programmes pour aller chercher l’information et la résumer.
Chez Cognition, l’éditeur de Devin, Walden Yan insiste sur autre chose : la capacité du modèle à démontrer que son travail fonctionne. Devin s’est servi d’Astra pour tester Otter Run, un jeu iPhone, et a renvoyé un enregistrement du jeu tournant dans un simulateur, accompagné d’un rapport listant les vérifications passées et les zones laissées de côté.
La preuve à la place du diff
Le livrable change de nature. L’ingénieur ne reçoit plus seulement un diff à lire ligne à ligne, mais un dossier : une vidéo montrant le comportement obtenu, un document délimitant le périmètre couvert. Il inspecte un résultat au lieu de reconstituer mentalement une intention à partir du code.
L’idée circule déjà ailleurs. Codex, l’agent de programmation d’OpenAI, accompagne chaque tâche de ses citations, de ses logs de terminal et du résultat de ses tests. Ce que l’éditeur de Devin y ajoute, c’est la vidéo du comportement obtenu et la liste de ce qui n’a pas été couvert.
Cognition en fait un objectif affiché : regarder de moins en moins de code à la main, et livrer davantage. Le support client suit le même chemin. Une capture d’écran de bug envoyée par un utilisateur part directement dans Devin, qui corrige et renvoie une capture du résultat. Le cycle de réponse se compte en minutes.
Chez Anthropic, la consigne est écrite à l’envers
Boris Cherny, qui travaille sur les outils de développement d’Anthropic, a formulé la règle maison : le code de production écrit par Claude doit passer une barre plus haute que s’il avait été écrit par un humain. Suit l’inventaire des garde-fous. Les règles de lint, cette analyse automatique qui traque les erreurs courantes et les écarts de style, sont multipliées, comme les tests, dont des tests end-to-end qui rejouent un parcours complet et que pilote Claude. S’y ajoutent des fuzzers exécutés chaque jour, ces programmes qui bombardent le code d’entrées aberrantes jusqu’à le faire céder, pilotés eux aussi par Claude, puis des revues de code et de sécurité automatisées et du refactoring automatisé. Sans cet appareillage, prévient-il, on se retrouve avec un ensemble difficile à maintenir.
Les deux discours ne se contredisent pas autant qu’il y paraît. Ils décrivent la même dépense et la rangent dans deux colonnes différentes. Perplexity et Cognition retirent des heures d’ingénieur du bilan. Anthropic ajoute des couches de machine à la place et, surtout, les compte.
Qui paie la vérification
Un harnais de test généré par le modèle qui vient d’écrire le code hérite de sa lecture du besoin. Si le modèle a mal compris ce qu’on attendait, le test confirmera une erreur avec application : il vérifiera que le programme fait bien ce que le modèle croyait devoir faire. La lecture humaine du diff, avec tous ses défauts, apportait au moins un second avis sur l’intention.
Le rapport de Cognition contient d’ailleurs l’élément le plus utile du dispositif, et le moins commenté : la liste des zones non testées. Une couverture déclarée honnête vaut mieux qu’une vidéo rassurante. Les équipes feraient bien d’en faire leur premier critère de lecture, avant l’enregistrement.
Reste la facture. Les fuzzers lancés chaque jour, les revues automatisées et les tests régénérés à chaque changement se paient en calcul et en temps machine. Une équipe qui supprime la relecture sans construire l’équivalent déplace le coût de la vérification vers la production, où il se règle en incidents.
Mi-2027, le dossier de preuve devient l’unité de revue
La suite se dessine déjà. Les outils d’agents devraient abandonner le diff comme objet principal de la revue. À sa place viendrait un dossier de preuve : enregistrement d’exécution, rapport de tests, couverture déclarée. Le code passerait au second plan. Cognition et Perplexity en montrent la version artisanale ; il manque le format commun qui permettrait de comparer deux dossiers entre eux.
Deux conditions décideront de la suite. La première est l’indépendance des tests vis-à-vis du code : tant que le même modèle écrit les deux dans la même session, la preuve tourne en rond. La séparation des rôles, un modèle qui écrit et un autre qui éprouve, devient une contrainte d’architecture. La seconde est la traçabilité : pouvoir dire qui, de l’humain ou du modèle, a écrit chaque test.
Ce qui accélérera le mouvement sera sans doute un accident : une panne sérieuse en production, attribuée publiquement à une suite de tests écrite par un modèle et validant le mauvais comportement. Les secteurs régulés exigeront alors la provenance des tests comme ils exigent aujourd’hui la revue à quatre yeux, et l’économie vantée cette semaine deviendra une ligne budgétaire assumée.
Mon avis
La vérification change de guichet. Ce que Perplexity et Cognition présentent comme moins de relecture, je le lis comme un transfert : l’ingénieur cesse de lire des lignes pour auditer des rapports, et il faudra bien quelqu’un pour auditer les rapports. Cherny dit la même chose depuis l’autre bout de la chaîne, à cette différence près qu’il l’écrit dans une consigne interne et non sur une page de témoignage client. D’ici deux ans, les équipes qui auront investi dans leur harnais de tests avanceront nettement plus vite que celles qui auront simplement accordé leur confiance.
