Article mis à jour le 20 septembre 2026 — sources consultées à cette date. Les perspectives sont des hypothèses, distinctes des résultats publiés.
L’intelligence artificielle change de rôle dans le développement logiciel. La question n’est plus seulement de savoir si elle peut écrire une fonction : il faut désormais évaluer sa capacité à comprendre un projet, modifier plusieurs composants, utiliser des outils et vérifier le résultat. Avec GPT‑6 Astra et Claude Fable 5.1, cette évolution devient très concrète. L’annonce d’une preuve concernant Navier–Stokes invite également à examiner une frontière plus ambitieuse : la contribution des systèmes d’IA à la découverte scientifique.
Cette accélération mérite mieux qu’un discours triomphaliste. Qu’a-t-on réellement démontré ? Quels résultats peut-on reproduire ? Que devient le métier de développeur ? Et lorsque la machine produit une réponse que nous n’aurions pas trouvée seuls, où situer l’intelligence, la compréhension et la responsabilité ?
GPT‑6 Astra et Codex : du code proposé au travail vérifié
GPT‑6 Astra est un modèle d’OpenAI ; Codex est l’environnement de travail dans lequel un agent peut mobiliser un modèle, des fichiers, un terminal et des outils connectés. Les deux ne doivent pas être confondus. Une capacité du modèle ne donne pas automatiquement accès à un dépôt privé, à une base de données ou à un site de production.
La documentation d’Astra décrit notamment le raisonnement, l’usage d’outils, l’orchestration de plusieurs agents et la possibilité d’intégrer des corrections pendant une tâche. Les appels d’outils asynchrones permettent à une application de poursuivre un travail indépendant pendant qu’un outil s’exécute. Ces fonctions ouvrent des possibilités d’automatisation, mais l’application conserve la responsabilité d’exécuter les outils et de gérer leurs autorisations. Documentation officielle d’Astra.
Pour une équipe de développement, voici des usages concrets à évaluer sur ses propres projets :
- Comprendre l’existant : cartographier les composants, identifier les dépendances, expliquer une règle métier et repérer les zones qui manquent de documentation.
- Préparer une évolution : proposer plusieurs architectures, expliciter leurs compromis et découper une migration en étapes contrôlables.
- Implémenter : modifier un frontend React, un service Node.js, une API ou une intégration WordPress en respectant les conventions du projet.
- Diagnostiquer : confronter une hypothèse aux journaux, reproduire un défaut et vérifier que la correction traite sa cause.
- Contrôler une interface : examiner le rendu, tester les liens, les formulaires, les états d’erreur et les usages sur petit écran.
- Préparer la livraison : expliquer les modifications, documenter les limites et établir une procédure de retour arrière.
Ce sont des possibilités de travail, pas une garantie de réussite pour chaque demande. Dans la collaboration ayant accompagné ce site, l’agent a par exemple modifié des pages, contrôlé des parcours de navigation et vérifié des liens. Ce retour d’expérience ponctuel ne constitue pas une mesure comparative de productivité.
La bonne unité de mesure n’est pas le nombre de lignes produites. C’est une fonctionnalité utile, compréhensible, testée et maintenable. Produire davantage de code inutile augmente aussi la charge de maintenance.
Claude 5.1 : préciser de quel modèle on parle
L’expression « Claude 5.1 » recouvre ici deux offres qu’il faut distinguer. Anthropic présente Claude Fable 5.1 comme son modèle généraliste pour les projets complexes et prolongés : développement, analyse documentaire et tâches utilisant plusieurs applications. Il peut notamment employer la vision pour contrôler une réalisation par rapport à son objectif. Présentation de Claude Fable 5.1.
Claude Mythos 5.1 partage le même modèle sous-jacent, avec des conditions d’accès et des protections différentes pour les usages sensibles en cybersécurité et en biologie. Son accès reste réservé à des organisations sélectionnées. Comparer un système de recherche ou une version disposant d’autorisations particulières avec une offre courante sans le préciser serait trompeur. Présentation de Claude Mythos 5.1.
Performances : une comparaison chiffrée, pas un classement absolu
Les valeurs ci-dessous proviennent du tableau publié par OpenAI pour Astra, consulté le 20 septembre 2026. Il s’agit de résultats rapportés par un fournisseur, pas d’un banc d’essai réalisé par Galion Software. Les versions des tests, les outils, les budgets de raisonnement et les protections influencent les scores.
| Évaluation | GPT‑6 Astra | Claude Fable 5.1 | GPT‑5.6 Sol |
|---|---|---|---|
| Terminal-Bench 4.0 | 57,9 % | 55,8 % | 37,3 % |
| DeepSWE v1.1 | 74,1 % | 67,4 % | 72,7 % |
| AutomationBench | 41,4 % | 31,4 % | 18,1 % |
| Terminal-Bench Science 0.1 | 64,6 % | 52,6 % | 22,4 % |
| FrontierMath Tier 4, v2 | 97,6 % | 87,8 % | 83,0 % |
| Humanity’s Last Exam, avec outils | 57,2 % | 65,0 % | Non indiqué |
Les écarts varient et Claude prend l’avantage sur la dernière ligne. Ces scores ne démontrent donc aucune supériorité universelle. OpenAI précise publier les meilleurs scores obtenus selon l’effort de raisonnement et avertit que son environnement d’évaluation peut différer des produits. Tableaux et protocoles publiés par OpenAI.
Pour choisir un modèle, nous recommandons un essai sur un petit ensemble représentatif : un défaut difficile, une évolution fonctionnelle, une reprise de données et un contrôle d’interface. Les mêmes exigences doivent s’appliquer à chaque candidat. Mesurer la qualité finale, le temps de relecture, les erreurs restantes et le coût total est plus instructif que de comparer des démonstrations choisies.
Un score de 60 % ne signifie ni « 60 % d’intelligence humaine », ni « 60 % des développeurs remplacés ». Il mesure une réussite selon un protocole particulier. Une amélioration sur ce protocole est une information utile ; sa généralisation à un métier entier est une hypothèse supplémentaire.
Navier–Stokes : ce que l’annonce change réellement
Les équations de Navier–Stokes décrivent le mouvement des fluides. Dans leur forme incompressible, elles associent l’évolution de la vitesse, le transport du mouvement, la pression, la viscosité et une éventuelle force extérieure. Le problème mathématique ne consiste pas à calculer une seule trajectoire : il demande notamment si des conditions initiales régulières peuvent mener à une singularité en dimension trois. Énoncé officiel du problème, Clay Mathematics Institute.
Le manuscrit publié par OpenAI construit un écoulement initialement au repos, soumis à une force lisse, dont la vitesse devient non bornée en temps fini, alors que l’énergie cinétique reste bornée. Il revendique ainsi les alternatives C et D de l’énoncé du Millénaire. Ce résultat porte sur un cas avec forçage extérieur ; il ne tranche pas à lui seul la régularité de tous les écoulements sans force extérieure. Manuscrit de la preuve, théorème 1.1.
L’image intuitive est celle d’un tourbillon dont le cœur se contracte et devient de plus en plus effilé. La vitesse augmente dans une région qui rétrécit. Des oscillations et des corrections annulent les termes indésirables pour maintenir la force extérieure régulière. Manuscrit, description physique et plan de preuve.
Cela ne fournit pas une formule universelle pour prévoir la météo ou toute turbulence. La preuve concerne un objet mathématique défini par des hypothèses précises ; une application industrielle demande d’autres modèles, des données et une validation expérimentale.
Combien de temps, et par quels moyens ?
Le repère historique est 1934, avec les travaux de Jean Leray : 92 ans jusqu’en 2026, soit environ neuf décennies pour la question de régularité. Les équations elles-mêmes remontent au XIXe siècle. Contexte historique du manuscrit.
Selon le récit d’OpenAI, le groupe décisif réunissait environ 10 000 agents utilisant un modèle interne plus puissant qu’Astra, des ressources documentaires et l’exécution de code. Les pistes ont été explorées en parallèle, puis leurs résultats intermédiaires partagés. Un résultat préalable sur Euler a orienté la recherche. La solution a été trouvée après 88 heures, suivies de 17 heures supplémentaires de formalisation et de vérification via GPT‑6 Astra. Annonce du 8 septembre 2026.
Ces durées décrivent une campagne de recherche. Elles n’incluent pas la constitution du savoir mathématique, le développement des outils, l’entraînement des modèles ou toute l’évaluation scientifique ultérieure. Opposer simplement « quelques jours de machine » à « un siècle d’humains » effacerait précisément les connaissances humaines qui rendent cette recherche possible.
La formalisation dans Lean permet d’exprimer une démonstration sous une forme vérifiable par un assistant de preuve. Elle déplace une partie de la confiance vers un contrôle explicite des étapes logiques. Il faut néanmoins examiner que l’énoncé formalisé correspond bien à la question annoncée et comprendre ses hypothèses. Cet article ne prétend ni avoir reproduit intégralement cette vérification, ni constater une attribution officielle du prix du Millénaire.
Pourquoi parler d’accélération, sans annoncer l’infaillibilité ?
Le changement marquant est la combinaison de plusieurs fonctions : proposer, agir, observer, corriger et recommencer. Une idée peut devenir une expérience exécutable ; son résultat peut alimenter une nouvelle hypothèse. Dans un domaine où la vérification est précise, comme certains tests logiciels ou une preuve formalisée, cette boucle dispose d’un signal de réussite plus net que dans une discussion ouverte.
Les progrès publiés constituent des indices sérieux d’accélération sur plusieurs tâches. Ils ne prouvent ni une progression uniforme dans tous les domaines, ni une croissance exponentielle qui se poursuivrait indéfiniment. Un système peut réussir un problème difficile et échouer sur une consigne simple. L’accès aux données, la qualité des outils, le coût du calcul et la possibilité de vérifier restent déterminants.
Pour les entreprises, cela plaide pour des expérimentations régulières, avec des critères stables. Une décision raisonnable il y a six mois peut mériter une nouvelle évaluation ; un nouvel outil ne justifie pas automatiquement de remplacer une solution fiable.
Trois perspectives pour les prochaines années
Les scénarios suivants sont des pistes de réflexion, pas des prévisions certaines.
Un développement plus accessible. Des équipes réduites pourraient réaliser des outils auparavant trop coûteux : interfaces métier, rapprochements de données, automatisations ciblées. Le facteur limitant se déplacerait vers la définition du besoin et la capacité à contrôler le résultat. Une demande imprécise automatisée à grande vitesse reste une demande imprécise.
Une recherche plus collective. Des systèmes pourraient explorer simultanément plusieurs hypothèses et produire des propositions que des spécialistes trient et vérifient. Le bénéfice dépendrait de la qualité du partage, de la reproductibilité et de la reconnaissance des contributions. Multiplier les agents sans organiser leur coordination peut aussi multiplier le bruit.
Une valeur accrue de la confiance. À mesure que la production devient moins chère, l’origine des données, la preuve du bon fonctionnement, la sécurité et la responsabilité prennent davantage de poids. Le fournisseur le plus utile pourrait être celui qui explique clairement ce qui a été contrôlé, ce qui reste incertain et comment revenir en arrière.
Le débat philosophique : réussir, comprendre, décider
Une machine qui trouve une preuve comprend-elle ce qu’elle démontre ? La réponse dépend du sens donné à « comprendre ». Si l’on entend relier des idées, exploiter des conséquences et résoudre une difficulté nouvelle, certains résultats invitent à élargir notre définition fonctionnelle de l’intelligence. Si l’on entend une expérience vécue du sens, les performances ne suffisent pas à trancher.
Il faut donc distinguer compétence observable, compréhension et conscience. Réussir un test ne règle pas automatiquement ces trois questions. Inversement, l’incertitude sur la conscience n’annule pas l’utilité d’une découverte correctement vérifiée.
La question politique est tout aussi importante : qui décide des objectifs ? Qui bénéficie du gain de productivité ? Qui assume un dommage ? Et comment répartir le mérite entre les chercheurs antérieurs, les équipes qui construisent les modèles, les personnes qui orientent le travail et les systèmes qui explorent les solutions ?
Nous pouvons souhaiter des outils plus capables sans leur abandonner le choix des finalités. Plus une IA peut agir, plus il devient nécessaire de préciser son mandat. Le débat fécond ne se réduit donc pas à « pour ou contre l’IA » : il porte sur les conditions dans lesquelles nous voulons déléguer, vérifier et partager ses bénéfices.
Notre approche chez Galion Software
Notre conviction est pratique : l’IA doit augmenter la capacité d’une entreprise à servir ses utilisateurs, sans rendre son système incompréhensible ou incontrôlable. Plus de 35 ans d’expérience métier et de développement apportent un cadre pour distinguer une démonstration séduisante d’une application durable.
Nous privilégions un besoin circonscrit, des données maîtrisées, une validation proportionnée au risque et des résultats observables. Les décisions concernant les données sensibles, les droits d’accès, les coûts et la mise en production doivent rester explicites.
Vous souhaitez identifier un premier usage pertinent ou moderniser une application ? Découvrez notre approche de l’intelligence artificielle appliquée en entreprise, nos exemples de modernisation d’applications ou présentez-nous votre projet.
Et vous : qu’attendriez-vous d’une IA capable de trouver une solution que vous ne savez pas encore expliquer — une réponse, une preuve, ou les moyens de la comprendre ?
