Un modèle plus intelligent ne suffit plus toujours à attirer davantage de développeurs. Selon Russell Kaplan, président et cofondateur de Cognition, de nombreuses tâches de génie logiciel atteignent désormais une forme de « saturation d’intelligence » : une fois qu’un modèle sait correctement les exécuter, la rapidité et le coût deviennent les critères décisifs.
La donnée la plus frappante concerne l’impact commercial de la performance. Chez Cognition, un avantage de 10 points en intelligence ne générerait plus que 20 % de trafic supplémentaire, contre près de 69 % à la fin de 2025. Cette évolution place le prix par tâche, le temps de réponse et la capacité à travailler en parallèle au centre de la compétition entre agents de codage.
Les tâches de développement atteignent un seuil de suffisance
L’idée défendue par Cognition est simple : dans une partie du développement logiciel, les modèles ont déjà franchi le seuil où ils produisent un résultat exploitable. Au-delà de ce seuil, gagner quelques points sur une évaluation ne change pas nécessairement l’expérience quotidienne du développeur.
« De nombreuses tâches de génie logiciel sont désormais saturées en intelligence. Une fois qu’un modèle sait bien faire la tâche, le coût et la rapidité sont les seuls éléments qui comptent », a écrit Russell Kaplan.
Cette analyse ne signifie pas que l’intelligence des modèles n’a plus de valeur. Elle indique plutôt que son rendement devient inégal selon les tâches. Comprendre une architecture complexe, corriger une faille de sécurité ou modifier un système ancien peut encore exiger un raisonnement approfondi. À l’inverse, écrire un test, transformer une structure de données ou corriger une erreur localisée peut déjà être suffisamment bien pris en charge par plusieurs modèles.
La distinction entre ces deux catégories devient essentielle pour évaluer un agent. Un modèle légèrement meilleur n’apporte pas forcément un bénéfice mesurable si le modèle concurrent produit déjà un correctif acceptable en quelques secondes. Dans ce cas, la latence, la facture et la capacité à relancer rapidement une tâche prennent le dessus.
L’écart de trafic s’est fortement réduit en 2026
Le chiffre communiqué par Cognition traduit un changement de valeur économique. Fin 2025, un avantage de 10 points en intelligence était associé à près de 69 % de trafic supplémentaire. En octobre 2026, le même avantage ne représenterait plus que 20 % de trafic supplémentaire.
L’écart reste positif, mais il s’est contracté de manière spectaculaire. Pour les fournisseurs, cette évolution réduit l’intérêt d’une stratégie fondée uniquement sur la course au modèle le plus performant. Une avance technique coûteuse doit désormais être convertie en gains visibles : réponses plus rapides, coût inférieur ou meilleure disponibilité.
| Indicateur | Fin 2025 | Octobre 2026 |
|---|---|---|
| Avantage mesuré pour 10 points d’intelligence | Près de 69 % de trafic supplémentaire | 20 % de trafic supplémentaire |
| Critères mis en avant | Intelligence du modèle | Rapidité et prix |
| Lecture de Cognition | Forte prime à la performance | Rendement décroissant de l’intelligence |
Cette tendance concerne surtout les tâches répétitives et bien délimitées. Elle ne permet pas de conclure que tous les usages du développement logiciel sont devenus interchangeables. Elle montre plutôt que le marché commence à distinguer la difficulté intrinsèque d’un problème de la fréquence à laquelle ce problème est rencontré.
Pour un fournisseur, cette distinction change la manière de concevoir un produit. Le meilleur système n’est plus nécessairement celui qui utilise le modèle le plus puissant à chaque étape. Il peut être celui qui réserve ce modèle aux tâches difficiles et emploie des modèles plus rapides pour les opérations courantes.
Devin mise sur le coût par tâche autant que sur le score
Devin, l’agent de génie logiciel développé par Cognition, illustre cette orientation. L’outil peut lire du code, le modifier, exécuter des tests et accomplir des tâches de développement. En septembre 2026, Cognition a annoncé des réductions de coût concernant plusieurs modes d’utilisation de Devin.
Les modes Fusion et Normal ont vu leur coût baisser de 30 à 40 %. Le mode Ultra a bénéficié d’une réduction comprise entre 15 et 20 %, tandis que Devin Review a enregistré une baisse pouvant atteindre 70 %.
Ces réductions ne sont pas un simple argument tarifaire. Elles répondent à une contrainte propre aux agents autonomes : une tâche peut mobiliser plusieurs appels à des modèles, des commandes dans un terminal, des itérations de correction et des exécutions de tests. Le prix d’une action unique devient alors moins pertinent que le coût total d’une tâche terminée.
Cognition a également communiqué des résultats sur FrontierCode 1.1. Devin Fusion a obtenu 68,8 sur la version Extended du benchmark, pour un coût moyen annoncé de 0,60 dollar par tâche. Sur le parcours principal, Devin a atteint 50,0 %, à moins d’un point de Fable 5.1 tout en affichant un coût inférieur de 64 % selon les données relayées.
Ces chiffres doivent être lus avec prudence : les benchmarks n’évaluent pas tous les mêmes capacités et les conditions de test peuvent varier. Ils illustrent néanmoins la direction prise par le produit, qui associe score d’évaluation et coût moyen d’exécution au lieu de mettre en avant la performance seule.
La rapidité devient une fonctionnalité produit
La rapidité ne se limite pas au temps nécessaire pour afficher une réponse. Pour un agent de codage, elle englobe la latence avant le premier résultat, la vitesse d’exécution des commandes, le temps d’attente entre deux étapes et la capacité à lancer plusieurs tâches simultanément.
Un agent plus rapide peut permettre à un développeur de tester davantage d’hypothèses dans la même journée. Il peut aussi rendre les échanges moins coûteux en attention : lorsqu’une correction arrive rapidement, le développeur reste dans le contexte du problème au lieu de passer à une autre activité.
La vitesse compte également dans les workflows parallèles. Un agent capable de traiter plusieurs tickets, branches ou scénarios en même temps peut augmenter le débit d’une équipe sans exiger que chaque développeur attende la fin d’une tâche avant d’en lancer une autre.
Cette logique favorise les architectures qui répartissent le travail entre plusieurs modèles. Un modèle rapide peut analyser les fichiers, générer une première correction ou produire une synthèse. Un modèle plus avancé peut ensuite intervenir sur les cas ambigus, les changements à fort risque ou les décisions d’architecture.
Le routage des modèles devient stratégique
Le routage de modèles, c’est-à-dire la sélection automatique du modèle adapté à chaque étape, devient l’un des moyens les plus directs de réduire la facture. Une tâche simple n’a pas besoin du même niveau de raisonnement qu’une migration complexe ou qu’une correction de sécurité.
Cette approche transforme l’intelligence en ressource à allouer. Le produit ne cherche plus à utiliser le modèle le plus puissant partout, mais à réserver la puissance là où elle augmente réellement la probabilité de réussite.
Pour le développeur, le résultat attendu reste le même : un code correct, testé et intégrable. La différence se situe dans le chemin emprunté pour l’obtenir. Si un modèle rapide réussit neuf tâches sur dix et qu’un modèle plus coûteux ne résout correctement que la dernière, le routage peut réduire fortement le coût global.
Les benchmarks confirment la tension entre score et efficacité
Les évaluations publiques des agents de codage montrent que le score n’est qu’une partie de la comparaison. Terminal-Bench, par exemple, mesure la capacité d’un agent à réaliser des tâches dans un terminal, mais les résultats dépendent de la version du benchmark, du modèle utilisé et du niveau d’effort autorisé.
Dans les données publiées en 2026, plusieurs systèmes obtiennent des scores élevés sur Terminal-Bench 2.1. Cognition a indiqué que Devin avait atteint 92,8 % sur cette version. D’autres tableaux publics recensent des résultats sur des versions différentes, ce qui empêche de comparer directement tous les chiffres.
Cette difficulté met en évidence un problème central : un score supérieur ne suffit pas à déterminer le meilleur outil pour une équipe. Il faut aussi connaître le coût des essais, le temps nécessaire pour terminer les tâches, la fréquence des erreurs et la quantité de supervision demandée.
| Critère | Ce qu’il mesure | Pourquoi il compte pour une équipe |
|---|---|---|
| Score de benchmark | Réussite sur un ensemble de tâches | Indique la capacité technique dans un cadre donné |
| Coût par tâche | Dépense moyenne pour obtenir un résultat | Permet d’estimer la facture réelle à grande échelle |
| Latence | Temps avant la réponse ou l’étape suivante | Influence le rythme de travail du développeur |
| Exécution parallèle | Nombre de tâches traitées simultanément | Mesure le débit possible sur un portefeuille de tickets |
| Taux de reprise | Fréquence des corrections ou relances nécessaires | Évalue la supervision réellement requise |
L’évaluation la plus utile dépend donc du travail à accomplir. Une équipe qui traite des tickets simples et nombreux peut privilégier le coût et la vitesse. Une équipe qui maintient un système critique peut accepter une latence supérieure si elle réduit les erreurs de conception ou les régressions.
À retenir : un score élevé ne décrit pas à lui seul la valeur d’un agent. Le coût par tâche, la durée d’exécution et le nombre de reprises déterminent souvent davantage la productivité réelle.
L’intelligence reste décisive pour les problèmes difficiles
La thèse de la saturation ne concerne pas toutes les activités de programmation. Les tâches qui exigent une compréhension globale du système continuent de bénéficier de modèles plus capables.
C’est notamment le cas des migrations importantes, des changements qui touchent plusieurs services, de l’analyse d’une base de code peu documentée et des corrections qui exigent de reconstituer une chaîne causale complexe. Dans ces situations, une erreur initiale peut entraîner plusieurs itérations et annuler le bénéfice d’un modèle rapide.
La sécurité constitue un autre domaine où la vitesse ne peut pas remplacer le raisonnement. Un agent doit comprendre les frontières de confiance, les droits d’accès, la gestion des secrets et les effets d’une modification sur les données. Un correctif produit rapidement mais incomplet peut créer un risque supérieur au gain de temps.
L’intelligence reste également importante lorsque le problème est mal spécifié. Un ticket clair peut être traité par plusieurs agents. Une demande vague, contradictoire ou liée à une décision produit nécessite davantage d’interprétation humaine et de raisonnement.
Le marché pourrait donc se diviser entre plusieurs catégories d’agents :
- Des agents rapides et peu coûteux pour les tâches répétitives.
- Des agents généralistes pour les tickets qui exigent une compréhension intermédiaire.
- Des agents plus lents et plus chers pour l’architecture, la sécurité et les changements à haut risque.
Cette segmentation ne supprime pas la course à l’intelligence. Elle réduit plutôt son caractère universel. La question ne sera plus seulement de savoir quel modèle est le plus intelligent, mais dans quelles situations cette intelligence supplémentaire produit un résultat meilleur.
Les développeurs devront mesurer le débit, pas seulement le modèle
Le choix d’un outil de codage ne peut plus reposer uniquement sur le nom du modèle ou sur son meilleur score publié. Les équipes ont intérêt à mesurer leurs propres tâches, avec leurs dépôts, leurs règles de revue et leurs exigences de test.
Un protocole interne peut commencer par un échantillon de tickets représentatifs. Chaque tâche doit être évaluée selon plusieurs dimensions : temps jusqu’à la première proposition utile, temps jusqu’à une solution validée, nombre de relances, coût total et volume de modifications acceptées.
Cette méthode permet de distinguer la vitesse apparente de la vitesse effective. Un agent qui répond en quelques secondes mais produit souvent des corrections inutilisables peut être plus lent au final qu’un agent qui prend davantage de temps et réussit du premier coup.
Les équipes doivent aussi examiner le niveau de supervision. Un outil qui demande une validation permanente ne produit pas le même gain opérationnel qu’un agent capable de préparer une modification, d’exécuter les tests et de présenter un résumé exploitable.
Les critères de sélection évoluent
Les critères pertinents pour comparer des agents de codage incluent désormais :
- Le coût moyen d’une tâche terminée, plutôt que le prix d’un appel isolé.
- Le délai nécessaire pour obtenir une modification testée.
- La capacité à travailler sur plusieurs tâches en parallèle.
- La compatibilité avec les dépôts, les environnements et les outils de l’équipe.
- La qualité des résumés, des tests et des propositions de correction.
- Le niveau de contrôle humain nécessaire avant intégration.
Cette approche favorise les produits qui publient des informations opérationnelles. Un score de benchmark reste utile, mais il doit être accompagné de données sur le coût et les conditions d’exécution pour éclairer une décision d’achat.
Notre avis : la vitesse gagne sur les tâches ordinaires, pas partout
La rapidité est en train de devenir le principal avantage concurrentiel des IA de codage pour les tâches déjà bien maîtrisées. Le chiffre avancé par Cognition, 20 % de trafic supplémentaire pour 10 points d’intelligence contre près de 69 % fin 2025, montre que la prime accordée à la performance brute se réduit rapidement.
La stratégie la plus crédible pour les six prochains mois n’est pas de remplacer les modèles avancés par des modèles rapides. Elle consiste à combiner les deux : utiliser des systèmes peu coûteux pour le volume et réserver les modèles les plus capables aux problèmes qui justifient leur coût.
Pour les développeurs, le bon réflexe sera de mesurer le temps jusqu’au code accepté, et non le temps jusqu’à la première réponse. Pour les fournisseurs, l’enjeu sera de prouver qu’un agent réduit réellement le coût d’une tâche complète, tests et reprises compris.
Cognition met ainsi en lumière une nouvelle phase du marché : après la course au modèle le plus intelligent, la compétition se déplace vers le modèle suffisamment intelligent, plus rapide et moins cher. Reste à savoir si cette logique s’étendra bientôt aux tâches de conception logicielle les plus complexes, ou si elles conserveront durablement une prime à l’intelligence.