L’essentiel
- Rashed Haq, vice-président véhicules autonomes de General Motors, chiffre à 15 % le temps que ses ingénieurs logiciels passent à écrire du code.
- En branchant des agents IA sur les 85 % restants, GM annonce environ trois fois plus de pull requests fusionnées, des releases plus rapides et moins de défauts échappés vers les étapes suivantes.
- Les agents accèdent aux outils internes et à des pétaoctets de données maison via des serveurs MCP développés sur mesure, avec des « skills » versionnés et les droits de l’ingénieur qui les lance.
- Le gain vient de la refonte des boucles d’ingénierie, pas de l’ajout d’un assistant de programmation dans l’éditeur.
Dans la division conduite autonome de General Motors, un ingénieur logiciel passe 15 % de son temps à écrire du code. Le reste part ailleurs : analyser les données remontées par les véhicules, trier les anomalies, monter des expériences, tester des correctifs. C’est sur cette part immergée que GM a lâché ses agents, et le nombre de pull requests fusionnées a environ triplé.
Le chiffre vient de Rashed Haq, vice-président véhicules autonomes du constructeur, interrogé sur scène à la conférence VB Transform 2026. Il l’accompagne de deux autres affirmations : des releases plus rapides et moins de défauts qui filent vers les étapes ultérieures du développement. Puis d’une précision qui pèse plus lourd que le triplement : ces gains viennent de la refonte de workflows entiers autour des agents. « Si vous donnez à quelqu’un un simple chatbot capable de programmer, il reste beaucoup d’inefficacité dans le processus », résume-t-il.
Écrire du code n’occupe qu’une minorité de la journée
Ce partage du temps surprend pour un métier qu’on appelle « développement ». Il recoupe pourtant ce que mesurait la recherche bien avant l’arrivée des agents. Une étude Microsoft de 2019, appuyée sur 5 971 développeurs professionnels, situe l’écriture de code à 96 minutes les bons jours et 66 minutes les mauvais : environ 20 % et 14 % d’une journée de huit heures. Une enquête Stripe de 2018 relevait de son côté plus de 17 heures par semaine passées à entretenir l’existant, débogage et refactoring inclus.
Les chercheurs de Microsoft précisent eux-mêmes qu’il n’existe pas de référence unique : selon la définition retenue, les travaux antérieurs placent la programmation entre 9 % et 61 % du temps de travail. La part avancée par GM est donc un ordre de grandeur interne, pas une constante du métier. Elle suffit néanmoins à poser le problème : accélérer l’écriture du code, c’est optimiser la tranche la plus courte de la chaîne. Le reste du secteur communique pourtant sur cette tranche-là : chez Google, Sundar Pichai chiffre à 75 % la part du code neuf produit par l’IA puis validé par un ingénieur, quand GM dit s’être attaqué aux 85 % qui restent.
Chercher le goulot, boucle par boucle
La méthode décrite par Haq tient en un mot : les boucles. GM a découpé son travail sur le véhicule autonome en cycles distincts : développement et test en simulation, essais sur route ouverte, surveillance des véhicules déjà livrés aux clients. Pour chaque boucle, l’équipe a identifié le goulot le plus long, l’a automatisé, puis a recommencé. « Procéder boucle par boucle est devenu très important », dit-il.
Rien d’exotique côté théorie : c’est de la gestion de contrainte appliquée à une organisation logicielle. L’intérêt est ailleurs. Un assistant installé dans l’éditeur accélère un poste de travail et laisse le cycle intact ; automatiser le goulot d’une boucle raccourcit le temps de traversée complet. Le même modèle, branché à deux endroits différents, ne produit pas du tout le même effet sur le calendrier.
Les agents branchés sur les outils maison par MCP
Côté plomberie, GM a relié ses agents aux outils internes et à des pétaoctets de données via des serveurs MCP (Model Context Protocol, le standard qui expose outils et sources de données à un modèle) développés sur mesure. L’entreprise y a ajouté des « skills » : des documents d’instructions versionnés qui décrivent comment exécuter une tâche donnée. Le prompt cesse d’être une trouvaille individuelle, il devient un artefact révisable comme du code.
Le cas d’usage le plus parlant concerne la télémétrie des véhicules en circulation. Un agent analyse les remontées, effectue un premier triage et ouvre des tickets pour les ingénieurs. Via MCP, il appelle directement les outils sous-jacents de WebViz, le système de visualisation de télémétrie de GM, au lieu de manipuler l’interface graphique destinée aux humains. La nuance est technique et décisive : piloter une API coûte moins cher et casse moins souvent que piloter des pixels.
Deux garde-fous encadrent le dispositif. La sortie doit rester lisible par un humain : l’agent signale un problème potentiel, localise le composant concerné, cherche des incidents comparables dans l’historique et fournit les exemples qui appuient sa conclusion. Ses permissions, ensuite, sont exactement celles de l’ingénieur qui l’utilise, pas celles d’un compte de service omnipotent. Et cet ingénieur reste responsable du résultat.
Trois fois plus de merges ne dit pas trois fois plus de travail
Le compteur brandi mérite quand même un examen. Une pull request n’a pas de taille standard : elle peut porter trois lignes ou trois mille. Or un workflow agentique pousse mécaniquement vers des changements plus petits et plus nombreux, chaque triage automatique produisant un ticket, et chaque ticket une contribution séparée. Un facteur trois sur les merges peut donc refléter un grain plus fin autant qu’une capacité de production réellement triplée.
Les propos publics ne disent rien de la taille moyenne des contributions, du taux de pull requests rejetées, ni du temps passé en revue. Un seul indicateur cité touche à la qualité : la baisse des défauts échappés, ceux qui traversent une étape de validation sans être détectés. C’est celui-là qui tranche, et c’est aussi le plus difficile à maquiller, parce qu’un défaut échappé se paie plus tard, en recalibrage, en immobilisation de flotte ou en incident sur la route.
Une équipe qui installe des agents a donc trois mesures à poser avant de compter les merges : le taux d’échappement des défauts, le délai médian de revue, la part des contributions annulées après coup. Sans ces mesures, un tableau de bord flatteur mesure surtout la quantité de code à relire.
Chez GM, la ligne de contrôle finale tient à une personne : l’ingénieur dont l’agent emprunte les droits et qui répond de ce qui part en production. Tant qu’il a le temps de lire ce qu’il signe, tripler le débit est un gain d’ingénierie solide. Passé ce seuil, le triage automatique n’aura fait que transférer la charge en aval : c’est la file d’attente devant la revue de code qui dira si l’organisation a réellement gagné en vitesse.
Mon avis
Je ne retiendrai ce triplement que le jour où GM publiera sa courbe de défauts échappés sur douze mois de flotte. Multiplier les pull requests par trois devient presque mécanique dès qu’on découpe le travail plus fin ; tenir la qualité avec trois fois plus de code fusionné, beaucoup moins. Et je situe le prochain goulot là où personne ne le budgète : la relecture humaine, seul poste que les agents chargent plus vite qu’ils ne le soulagent.
