Critic : quand l’IA qui code doit justifier son travail

Quand l’IA devient trop productive

Chez Feyn, entreprise spécialisée dans la construction de modèles IA personnalisés, un constat s’est imposé : les agents IA écrivent désormais la majorité du code. Une victoire pour la productivité, mais un casse-tête pour la compréhension. « Comprendre un changement et ses conséquences est devenu incroyablement difficile », explique Shreyash, représentant de l’entreprise, dans l’annonce publique du produit sur Hacker News.

Le paradoxe est frappant : une entreprise qui construit de l’IA se retrouve dépassée par ses propres outils. Quand un agent comme Claude Code ou Codex génère 500 lignes de code fonctionnel en quelques minutes, comment s’assurer que les choix architecturaux sont pertinents ? Comment expliquer à un nouveau développeur pourquoi telle approche a été privilégiée ? Les outils traditionnels de code review – GitHub, GitLab, Bitbucket – n’ont jamais été conçus pour du code écrit par des non-humains.

Critic : faire parler le code

La solution imaginée par Feyn s’appelle Critic, et elle inverse la logique habituelle. Au lieu de simplement lire passivement du code généré par IA, les développeurs peuvent désormais interroger directement l’agent qui l’a écrit.

Le fonctionnement repose sur un plugin intégré à Codex (OpenAI) ou Claude Code (Anthropic). Lorsqu’un agent écrit du code, le plugin lui demande automatiquement de produire un résumé du changement, d’annoter les blocs clés et d’inclure des preuves contextuelles : captures d’écran, instructions pour tester localement, justifications des choix techniques.

Mais l’innovation va plus loin. Une fois la Pull Request créée, n’importe quel membre de l’équipe peut engager une conversation avec l’agent auteur. « Pourquoi avoir utilisé cette structure de données plutôt qu’une autre ? » « Ce bloc est-il optimisé pour de gros volumes ? » « Quelles sont les implications de sécurité de cette approche ? » L’IA répond en contexte, avec accès à sa propre « mémoire » du processus de développement.

La dette de compréhension, nouveau fléau du développement

Le problème que Critic cherche à résoudre porte un nom : la dette de compréhension. Un concept émergent, distinct de la dette technique traditionnelle.

La dette technique désigne du code de mauvaise qualité qu’il faudra refactoriser plus tard. La dette de compréhension, elle, concerne du code potentiellement excellent, mais que l’équipe ne comprend pas pleinement. « Le code marche, mais personne ne peut expliquer pourquoi certaines décisions ont été prises », résume un développeur confronté à ce phénomène.

Selon l’expérience de Feyn, le seuil critique se situe autour de 30% de code généré par IA. Au-delà, les outils de review classiques montrent leurs limites. Les équipes passent plus de temps à déchiffrer le code qu’à le valider. La vitesse de développement augmente, mais la vélocité réelle (valeur livrée) stagne, voire régresse.

Cette dette s’accumule silencieusement. Jusqu’au jour où un bug critique survient, ou qu’un développeur clé quitte l’entreprise, emportant avec lui la compréhension contextuelle que l’IA n’avait jamais documentée.

Un outil né de l’urgence interne

Critic n’est pas le fruit d’une analyse de marché, mais d’une nécessité opérationnelle chez Feyn. « À mesure que notre entreprise adoptait plus d’outils agentiques, il devenait plus difficile d’informer les équipes de l’impact d’une PR et de l’état d’un projet », explique Shreyash.

Cette approche « dogfooding » (utiliser son propre produit pour résoudre ses problèmes) donne de la crédibilité au projet. Si une entreprise qui construit de l’IA a besoin d’outils pour gérer sa propre production automatisée, c’est que le problème est structurel, pas anecdotique.

La démonstration vidéo publiée par Feyn montre un workflow fluide : l’agent annote son code avec des marqueurs explicatifs (« ⚠️ Cette fonction utilise un algorithme optimisé pour les grands datasets »), inclut des screenshots de l’interface modifiée, et propose des commandes pour tester localement. Le reviewer peut ensuite cliquer sur n’importe quel bloc et ouvrir un dialogue contextuel avec l’agent.

Questions ouvertes et zones d’ombre

Malgré l’intérêt suscité, plusieurs aspects restent flous. Le modèle économique n’est pas communiqué : Critic sera-t-il gratuit, freemium, ou payant dès le départ ? Quel sera le coût par interaction, sachant que chaque question à l’agent consomme des tokens API potentiellement coûteux sur de grandes PR ?

La question de la véracité des explications est également centrale. Les grands modèles de langage sont connus pour leurs hallucinations – ces moments où ils génèrent des informations plausibles mais fausses. Comment garantir que l’agent explique vraiment ce qu’il a fait, et non ce qu’il pense avoir fait ? Feyn n’a pas encore détaillé les garde-fous techniques mis en place.

Autre interrogation : la dépendance aux plateformes. Critic repose sur Codex et Claude Code, dont les APIs et politiques peuvent évoluer. Que se passe-t-il si OpenAI ou Anthropic modifient leurs conditions d’accès, ou intègrent directement ces fonctionnalités dans leurs produits ?

Enfin, la sécurité soulève des questions. Les annotations automatiques pourraient révéler des informations sensibles sur l’architecture ou des vulnérabilités. Un attaquant pourrait-il « interroger » l’agent pour extraire des informations qu’il n’aurait pas obtenues en lisant simplement le code ?

Implications pour l’industrie

Si Critic rencontre son public, les répercussions pourraient être significatives. Pour les développeurs, une nouvelle compétence émerge : savoir interroger efficacement le code IA. Ce n’est plus seulement de la lecture de code, mais une forme d’investigation conversationnelle.

Les lead developers et architectes voient leur rôle évoluer. De « codeurs seniors », ils deviennent « curateurs et validateurs de code IA ». Moins de temps à écrire, plus de temps à valider, challenger, et s’assurer de la cohérence architecturale globale.

Pour les entreprises, la question de la gouvernance devient centrale. Qui est responsable d’un bug dans du code écrit par une IA, validé via un dialogue avec cette même IA ? Les frameworks juridiques actuels ne fournissent pas de réponse claire.

Du côté des plateformes établies (GitHub, GitLab), la pression monte. Elles devront soit développer des fonctionnalités similaires, soit acquérir des acteurs comme Critic. Microsoft, propriétaire de GitHub et partenaire d’OpenAI, dispose d’atouts considérables pour intégrer nativement ce type de capacités.

Trois scénarios pour l’avenir

Scénario 1 – Intégration native : Dans les 6-12 mois, GitHub ou Anthropic intègrent des fonctionnalités de dialogue avec le code IA directement dans leurs produits. Critic est soit acquis, soit marginalisé par des géants disposant de plus de ressources.

Scénario 2 – Plateforme d’orchestration : Critic évolue au-delà du simple code review. L’entreprise ajoute la gestion de projet, le testing automatisé, la documentation interactive. Elle devient une plateforme complète de collaboration humain-IA, positionnée comme le « Jira de l’ère des agents ».

Scénario 3 – Standard de niche : Critic reste un outil pour équipes early adopters, très dépendantes de l’IA générative. Adoption limitée mais loyale, avec une position défendable sur un segment spécifique (entreprises produisant >50% de code via IA).

Au-delà de l’outil, un changement de paradigme

Critic révèle une transformation rarement explicite : nous passons de « l’IA qui aide à coder » à « l’IA qui code et doit justifier ses choix ». C’est une inversion de la charge de la preuve dans le développement logiciel.

Traditionnellement, un développeur junior soumet du code qu’un senior valide. Avec les agents IA, c’est l’inverse : l’IA produit massivement, et l’humain – quel que soit son niveau – doit valider en interrogeant. Cette dynamique préfigure l’évolution de nombreux métiers intellectuels.

Le concept de « code conversationnel » émerge : du code qui peut expliquer ses propres décisions en langage naturel, de manière interactive. Si cette approche se généralise, la documentation technique traditionnelle pourrait devenir obsolète. Au lieu de lire des wikis poussiéreux, les nouveaux développeurs « discuteraient » directement avec le code pour comprendre un projet.

Reste une question fondamentale, que Critic ne résout pas seul : les développeurs juniors pourront-ils encore apprendre efficacement si la majorité du code est écrite par IA ? Le risque est réel de former une génération capable d’interroger le code, mais incapable de l’écrire from scratch quand nécessaire.

Conclusion : productivité ou compréhension ?

Critic incarne le dilemme central de l’ère des agents IA : comment maintenir la compréhension humaine face à une productivité machine exponentielle ? La solution proposée – faire dialoguer l’humain avec l’IA auteure – est élégante, mais soulève autant de questions qu’elle n’en résout.

Dans un contexte où l’Union européenne finalise son AI Act, avec des exigences de transparence et traçabilité, des outils comme Critic pourraient rapidement passer du statut de « nice to have » à celui de « compliance requirement ». Les entreprises qui documentent aujourd’hui qui (humain ou IA) a écrit quoi auront un avantage réglementaire demain.

Une chose est certaine : le développement logiciel de 2025 ne ressemble déjà plus à celui de 2020. Et si Critic tient ses promesses, celui de 2027 sera à nouveau méconnaissable. La question n’est plus de savoir si l’IA codera à notre place, mais comment nous maintiendrons notre capacité à comprendre, juger et corriger ce qu’elle produit.