Calipia : le blog

Les agents de code ne sont plus une curiosité de laboratoire. Chez certains éditeurs, ils produisent désormais l’essentiel du code qui part en production : Anthropic affirme ainsi que Claude rédige environ 80 % de son nouveau code de production. Le gain de vitesse est réel, mais il déplace le problème. La question n’est plus de savoir comment écrire du code plus vite, mais comment éviter que des dizaines d’agents travaillant en parallèle ne produisent un ensemble incohérent, contradictoire avec les règles de l’entreprise, ou tout simplement impossible à relire par les humains censés en porter la responsabilité.

C’est sur ce terrain que se positionne G5 Labs, une jeune pousse issue du MIT CSAIL qui sort de l’ombre avec un tour d’amorçage de 14 millions de dollars. Son fondateur, Tim Kraska, n’est pas un inconnu : professeur au MIT, ancien de Google Brain où il a conçu les « Learned Indexes », passé par Amazon comme directeur de la science appliquée, et cofondateur d’Einblick Analytics dont l’équipe a été reprise par Databricks en 2024. Le site de l’entreprise annonce la couleur avec un slogan qui ne fera pas l’unanimité dans les open spaces : la programmation serait morte, l’ingénierie se porterait à merveille.

L’ontologie système, ou l’intention promue au rang de code source

Le premier produit, baptisé simplement G5, est une plateforme web hébergée dans le cloud. Son principe consiste à transformer les exigences métier, les décisions d’architecture, les politiques internes et plus largement toute l’intention humaine qui entoure un logiciel en ce que la société appelle une « ontologie système ». Concrètement, il s’agit d’un graphe sémantique structuré qui sert de référence commune aux humains comme aux agents.

La thèse de Kraska est limpide : le langage naturel, encadré par une structure formelle, devient le véritable code source, tandis que le Python, le Rust ou le Java ne sont plus que des artefacts dérivés. L’analogie revendiquée est historique : de la même façon que les langages de haut niveau ont relégué l’assembleur au rang de détail d’implémentation, l’intention exprimée en langage naturel reléguerait les langages de programmation actuels. G5 Labs insiste sur quatre propriétés de cette nouvelle couche : elle serait compilable, fusionnable, comparable (au sens d’un diff) et gouvernable.

Sur le plan fonctionnel, l’ontologie ne se limite pas à une spécification de fonctionnalités. Selon David Chang, directeur des opérations et ancien responsable go-to-market des modèles Nova chez Amazon, elle embarque le modèle de données, les règles métier, les workflows, mais aussi les politiques transverses de l’entreprise : sécurité, RGPD, infrastructure, standards de codage. Chaque nœud du graphe est rédigé en langage naturel et relié au code qui l’implémente, de sorte que chaque ligne puisse être rattachée à une exigence. Le système audite en continu la cohérence interne de l’ontologie et la conformité du code à celle-ci.

Le cœur technique repose sur un compilateur bidirectionnel. Dans le sens montant, G5 analyse un code existant et ses éventuelles spécifications pour en extraire un premier graphe sémantique, organise les workflows et les décisions de conception en nœuds, puis soumet cette représentation à une revue humaine. Dans le sens descendant, les modifications validées au niveau de l’ontologie sont « redescendues » vers du code classique. Les exemples publiés montrent un code généré portant des métadonnées de traçabilité, sous la forme d’un commentaire pointant vers un concept de l’ontologie et une révision précise. La promesse marketing tient en une formule : modifiez l’intention et le code se réécrit, modifiez le code et l’ontologie apprend.

Les observateurs attentifs noteront une parenté conceptuelle avec l’Ontology de Palantir, qui modélise sémantiquement le monde opérationnel d’une entreprise. G5 applique une logique voisine au cycle de vie du logiciel : décrire ce que l’application doit faire, pourquoi certaines décisions ont été prises, et comment ces décisions se traduisent dans le code.

Le merge sémantique, argument le plus intéressant

Là où G5 se distingue d’un simple générateur de code à partir de prompts, c’est dans le traitement des conflits. Kraska illustre le sujet avec un exemple volontairement trivial. Deux développeurs, ou deux agents, modifient la même application bancaire. Le premier exige qu’un bouton soit rouge. Le second n’a exprimé aucune préférence et son agent a généré, au hasard, un bouton bleu. Au niveau du code source, Git signalera un conflit. Au niveau sémantique, il n’y en a aucun : une seule des deux parties a formulé une exigence, la fusion peut donc être automatique. À l’inverse, deux exigences d’authentification incompatibles constituent un vrai conflit sémantique qui doit remonter à un décideur humain.

L’interface présentée à la presse comprend un « Diff Graph » reliant les échanges et documents humains aux concepts de l’ontologie, aux composants d’architecture et aux fichiers sources. D’autres écrans affichent l’état de revue des blocs d’ontologie et d’implémentation, la progression et la couverture de tests, et découpent la création de pull requests, le rebase, l’approbation et le merge en étapes gouvernées.

L’intérêt pour une DSI est évident : pouvoir relire un changement au niveau de sa signification plutôt qu’au niveau de son texte, et permettre à des profils non développeurs (product owners, responsables conformité, RSSI) d’inspecter une représentation qu’ils comprennent. Kraska justifie cette approche par un constat qu’il assume sans détour : lorsqu’un ingénieur soumet une modification de 100 000 lignes, les mécanismes de revue traditionnels s’effondrent. Il précise d’ailleurs qu’un membre de son équipe a récemment poussé 300 000 lignes en une semaine sur la plateforme elle-même. On appréciera l’ironie involontaire : l’anecdote censée démontrer la nécessité de G5 décrit exactement le type de pratique qui fait transpirer les responsables qualité. Qui a relu ces 300 000 lignes, et à quel niveau d’abstraction ? La réponse attendue est évidemment « l’ontologie », mais c’est précisément ce qu’il reste à prouver.

Modernisation du legacy : ne pas porter la dette technique d’un langage à l’autre

Les premiers clients de G5 Labs se répartissent entre deux usages. Le premier est la modernisation d’applications historiques. Environ 90 % des organisations accompagnées appartiennent aux services financiers, sans qu’aucun nom ne soit communiqué pour des raisons de confidentialité.

La critique adressée aux outils de modernisation classiques est pertinente. La plupart se contentent de traduire l’ancien code vers un nouveau langage à l’aide de l’IA, transportant au passage toutes les décisions contestables prises jadis sous la pression des délais. On obtient alors un COBOL écrit en Java, ce qui n’est une victoire pour personne. G5 propose de remonter d’abord à la sémantique du système, de laisser l’entreprise examiner quelles hypothèses historiques restent valides, d’ajuster les exigences ou l’architecture, puis de régénérer une implémentation neuve. Les supports de lancement évoquent un projet dans la finance où la comparaison au niveau de l’ontologie aurait révélé des défauts structurels qu’un portage direct aurait masqués. Le site revendique « des millions de lignes » déjà remontées en ontologies. Ces chiffres sont déclaratifs et n’ont pas été vérifiés de façon indépendante, ce qui, dans un dossier d’achat, n’est pas un détail.

Remplacer le SaaS : l’argument qui mérite le plus de prudence

Le second usage est plus provocateur : remplacer des applications SaaS coûteuses par des applications sur mesure, construites, possédées et contrôlées par l’entreprise. Le raisonnement de Kraska est économique. Si l’IA écrase le coût d’implémentation, les entreprises accepteront de moins en moins de payer des primes élevées pour des logiciels génériques dont elles n’utilisent qu’une fraction des fonctions.

L’argument n’est pas absurde, mais il occulte une partie du coût total de possession. Un SaaS ne vend pas uniquement des fonctionnalités : il vend aussi l’exploitation, la sécurité opérationnelle, la conformité réglementaire, les mises à jour, la mutualisation des correctifs et une feuille de route. Générer une application de gestion des notes de frais est une chose. En assurer le run, la réversibilité, l’hébergement, les audits et la maintenance pendant dix ans en est une autre. Les DSI qui ont vécu l’époque des développements spécifiques « qui ne coûtaient presque rien » savent comment se termine généralement ce film.

Au-dessus des agents, pas à leur place

G5 Labs a eu la sagesse de ne pas vouloir concurrencer les laboratoires de modèles frontières. La plateforme se place au-dessus de la couche des modèles et des harnais de code. Elle pilote Claude Code, Codex ou des modèles open-weight, et peut choisir le modèle selon la tâche : un modèle frontière coûteux pour les décisions structurantes, un modèle plus économique pour le travail simple. Le site résume ce positionnement par l’absence de dépendance à un laboratoire unique.

Techniquement, G5 décompose un plan approuvé en tâches vérifiables, coordonne plusieurs agents en parallèle et consigne dans l’ontologie leurs décisions, leurs apprentissages et leurs étapes intermédiaires, aux côtés des règles d’architecture et des politiques propres au client. La plateforme joue donc aussi le rôle d’orchestrateur qui découpe, contraint et réconcilie le travail des agents.

Des garde-fous financiers sont prévus. Une demande formulée en apparence anodine en langage naturel peut impliquer une refonte d’architecture complète : G5 estime alors le coût prévisionnel et exige une confirmation supplémentaire avant de consommer le moindre token. Voilà une fonctionnalité que bien des directeurs financiers aimeraient voir généralisée.

Deux remarques critiques s’imposent toutefois. D’abord, G5 constitue une couche supplémentaire dans la pile et non un substitut à la dépense en modèles : la facture de G5 s’ajoutera à celle d’Anthropic, d’OpenAI ou d’autres. Ensuite, la dépendance ne disparaît pas, elle se déplace. Si l’ontologie devient l’artefact le plus stratégique du cycle de vie logiciel, l’entreprise sera dépendante de celui qui la stocke, la compile et en définit le format. Sortir de Claude Code pour Codex sera peut-être indolore, sortir de G5 le sera beaucoup moins.

Rien de nouveau sous le soleil ? Pas tout à fait

Les architectes aux tempes grisonnantes auront immédiatement pensé au Model Driven Architecture. L’Object Management Group en a fait le socle de ses standards dès 2001 : partir d’un modèle indépendant de la plateforme décrivant les fonctions métier, le transformer en modèles spécifiques puis en implémentations, et régénérer le code au gré des évolutions technologiques. L’idée que le modèle survit à l’implémentation n’a donc rien de révolutionnaire. Ceux qui ont pratiqué les outils de « round-trip engineering » de l’époque se souviennent aussi que la synchronisation modèle-code survivait rarement au premier correctif appliqué directement en production un vendredi soir.

Le marché actuel est par ailleurs déjà encombré :

AveriSource analyse les applications historiques, en extrait règles métier et structures de données dans un modèle intermédiaire, puis génère du Java, du C# ou des microservices. Son offre Reimagine utilise des spécifications métier structurées comme entrée d’une réingénierie assistée par IA.

Amazon Kiro propose un workflow piloté par les spécifications produisant des fichiers requirements.md, design.md et tasks.md, avec des exigences exprimées en notation EARS testable. Il détecte contradictions et omissions avant l’implémentation, et ses fichiers de « steering » encodent architecture et conventions. La version entreprise ajoute un contrôle centralisé des modèles et serveurs MCP, la journalisation des prompts et des analyses d’usage.

GitHub Spec Kit, projet open source sous licence MIT, se présente comme un harnais orienté intention compatible avec des dizaines d’agents. Son modèle de « spécification vivante » fait de spec.md le contrat à partir duquel les artefacts en aval sont régénérés, et il fonctionne hors ligne voire en environnement isolé. Surtout, sa commande /speckit.converge, apparue en 2026, confronte le code existant à la spécification, au plan et aux tâches, identifie les implémentations manquantes, partielles, contradictoires ou non demandées, puis crée des tâches de remédiation traçables. Pour les organisations déjà équipées de GitHub Enterprise et de Copilot, c’est un point de départ naturel qui ne coûte rien en licence.

Tessl, un temps associé au concept de « spec as source », s’est depuis recentré sur les compétences d’agents, les plugins, les évaluations et la gouvernance, avec SSO SAML, BYOK, auto-hébergement et audit.

La nouveauté revendiquée par G5 est donc plus étroite, et paradoxalement plus intéressante, que le slogan. Il ne s’agit pas d’avoir des spécifications, tout le monde en a. Il s’agit de maintenir un graphe sémantique à l’échelle de toute l’application, ancré dans l’implémentation dans les deux sens, qui distingue l’intention humaine des choix faits par les agents, détecte les conflits au niveau du sens et applique une gouvernance transverse. Kraska résume son positionnement ainsi : prendre les spécifications produites par des outils comme Kiro ou Spec Kit et les organiser en un graphe de connaissance cohérent, puis y ajouter l’ancrage, la compilation bidirectionnelle, le merge sémantique et les workflows d’approbation. Si cela fonctionne à l’échelle d’un SI bancaire, c’est une vraie avancée. C’est aussi infiniment plus difficile que de générer des fichiers Markdown.

Les angles morts techniques

Plusieurs questions de fond restent en suspens.

La première tient à la nature même du langage naturel. Il est ambigu par construction, et c’est précisément pour cette raison que des notations comme EARS ont été inventées. Qualifier une intention rédigée en anglais de « compilable » suppose une couche de structuration dont on connaît encore mal la rigueur. Un compilateur classique est déterministe ; un compilateur fondé sur des LLM ne l’est pas. Régénérer deux fois la même ontologie produira vraisemblablement deux codes différents. L’équivalence de comportement observable devra donc être garantie par des tests, et la qualité de ces tests devient elle-même un point critique.

La seconde concerne la dérive. Toute représentation parallèle au code finit par diverger dès que quelqu’un intervient en dehors de l’outil. G5 promet que l’ontologie « apprend » des modifications de code, mais la robustesse de cette remontée sur un code modifié par des équipes multiples, des prestataires et des scripts d’urgence reste à démontrer.

Petite illustration savoureuse : sur la page d’accueil de G5 Labs, l’exemple de module de notes de frais présente un nœud d’ontologie « Fraud Policy » avec un seuil de signalement fixé à 250 dollars, tandis que le code généré, affiché fièrement comme synchronisé, déclenche la revue manuelle au-delà de 500 dollars. Coquille de maquettiste, sans doute. Mais on peine à imaginer meilleure démonstration de la raison pour laquelle on voudra vérifier la synchronisation par soi-même.

Enfin, G5 Labs cite sur son propre site des études qui éclairent le contexte : une hausse de 47 % du volume de pull requests dans les équipes fortement utilisatrices d’IA selon Faros AI, et une étude du METR mesurant des mainteneurs open source expérimentés 19 % plus lents avec des outils d’IA. Ces chiffres justifient le besoin d’une meilleure gouvernance, ils ne prouvent en rien que la solution de G5 y répond.

Disponibilité et prix : on en reparlera 🙂

G5 ne propose pas d’offre en libre-service. Le déploiement standard est un environnement hébergé dans le cloud auquel le client accède avec des identifiants, et l’éditeur affirme pouvoir s’adapter aux contraintes plus strictes des banques. Pour la modernisation, le client ingère son système seul ou accompagné par G5 pour construire l’ontologie initiale. Les données resteraient la propriété de l’entreprise, et la plateforme pourrait s’appuyer sur les contrats existants du client avec les fournisseurs de modèles, y compris des accords sans rétention de données.

Quant au prix, Tim Kraska reconnaît que le modèle n’est pas encore arrêté. À titre de comparaison, Kiro va d’une offre gratuite à des forfaits de 20 à 200 dollars par utilisateur et par mois, Spec Kit est gratuit hors coût des agents et des modèles, et Tessl affiche 100 dollars par mois pour une équipe avec une tarification entreprise sur mesure. Pour G5, il faudra additionner l’abonnement futur, la consommation de modèles, l’effort de migration, la construction de l’ontologie et la charge de gouvernance continue.

Ce qu’une DSI devrait exiger avant de signer

Un POC sérieux ne se fera pas sur une application de démonstration flambant neuve, mais sur une application brownfield réelle, idéalement mal documentée. Il faudra vérifier que G5 retrouve l’intention métier d’un code inconnu, conserve les correspondances après des modifications faites hors plateforme, distingue les vrais conflits sémantiques des différences d’implémentation sans importance, applique les politiques internes sans noyer les équipes sous les faux positifs, et régénère une partie du système vers une pile technique sensiblement différente en préservant le comportement observable. Une piste d’audit complète, expliquant pourquoi chaque changement existe et à quelle intention approuvée il se rattache, doit être non négociable.

Côté exploitation, les questions ouvertes sont nombreuses : exportabilité et format de l’ontologie, reprise sur incident, options d’isolation et de déploiement, engagements de service, gestionnaires de sources supportés, contrôles d’administration et réversibilité. Pour un lecteur européen, s’ajoutent la localisation de l’hébergement, l’exposition aux législations extraterritoriales et, pour les établissements financiers qui constituent l’essentiel de la clientèle visée, l’inscription de ce nouveau prestataire critique dans le registre des prestataires TIC exigé par DORA.

Conclusion

G5 Labs bénéficie de soutiens de poids. Jeff Dean salue une tentative sérieuse et bien conçue d’élever à nouveau le niveau d’abstraction du logiciel, et Max Schireson, associé chez Battery Ventures et ancien PDG de MongoDB, va jusqu’à prédire que l’anglais remplacera bientôt Java, C, Python et Rust. Tim Kraska, lui, se montre plus mesuré sur l’avenir des développeurs : ils ne disparaîtraient pas, mais deviendraient des managers d’employés virtuels, concentrés sur les décisions d’architecture et d’exploitation.

La décision qui attend les DSI est heureusement moins vertigineuse que la prophétie de Schireson. Nul besoin de trancher aujourd’hui la mort de Java. Il s’agit de déterminer si le flot croissant de code produit par les agents mérite une couche sémantique et de gouvernance durable au-dessus du code source, et si G5 Labs peut rendre cette couche suffisamment fiable pour lui confier le cœur du SI. La première question appelle probablement un oui. La seconde appelle un POC, un contrat soigneusement rédigé et une bonne dose de scepticisme. Car avant que la langue courante ne remplace les langages de programmation, il faudra qu’elle cesse d’être ambiguë, y compris dans une spécification rédigée à 18 heures un vendredi.