IA agentique : ce que c'est vraiment

Le débat sur l’IA dans le développement logiciel s’est polarisé en deux camps qui se crient dessus depuis deux ans. D’un côté, les clips Twitter où un agent génère une app complète en 90 secondes, avec une musique épique en fond sonore. De l’autre, le dev expérimenté qui te sort que l’IA ne comprendra jamais vraiment le borrow checker de Rust, donc c’est fondamentalement limité.

Les deux ont partiellement raison. Les deux ratent l’essentiel.

Les deux camps qui ont tous les deux tort

La démo à deux phrases qui “build a SaaS in 10 minutes”, on en a tous vu. Le prompt est soigneusement préparé, la tâche est bornée, le contexte est propre, et on coupe avant les cas edge. Ce n’est pas du mensonge, c’est de la sélection. Le problème, c’est que les réseaux sociaux amplifient la démo parfaite et enterrent les dix tentatives précédentes qui ont produit du code cassé.

En face, le sceptique absolu a une autre erreur de raisonnement : il pose la mauvaise question. “Est-ce que l’IA comprend vraiment ce qu’elle fait ?” ce n’est pas une question d’ingénierie, c’est presque de la philosophie. La bonne question c’est : “Est-ce que ça fonctionne assez bien, assez souvent, pour que ce soit utile ?” Et là, la réponse est franchement plus intéressante.

Ce que les deux camps évitent de regarder en face, c’est la mécanique réelle de ces systèmes. Pas la magie, pas la limitation fondamentale. Juste ce que c’est.

Ce qu’est vraiment un agent IA

Dépouillé du marketing, un agent IA c’est un modèle de langage, des outils, et une boucle.

Le modèle reçoit un contexte (la conversation, l’état actuel, les résultats des actions précédentes) et produit soit une réponse finale, soit un appel à un outil. L’outil s’exécute, son résultat revient dans le contexte, et ça recommence jusqu’à ce que le modèle décide que c’est terminé, ou qu’on atteigne une limite.

graph TD
    A[Requête utilisateur] --> B[LLM]
    B -->|Appel outil| C[Exécution outil]
    C -->|Résultat| B
    B -->|Réponse finale| D[Utilisateur]
    B -->|Nouvel appel| C

C’est tout. Pas de raisonnement mystérieux, pas de conscience émergente. Un while loop avec un LLM qui fait le condition check à chaque itération.

Ce pattern simple produit des comportements qui ressemblent à de la planification, de la déduction. Mais c’est de la prédiction statistique sophistiquée, très puissante dans les cas couverts par l’entraînement, beaucoup moins robuste hors des sentiers battus.

Un système qui ne rejoue pas deux fois la même partition

C’est le point que les devs comprennent mal en premier, et qui change tout : à prompt identique, un LLM produit des résultats différents.

Ce n’est pas un bug. C’est une propriété fondamentale de ces modèles, la température et le sampling stochastique font partie du design. Mais pour un dev habitué aux systèmes déterministes, c’est un choc culturel. Tu ne peux pas écrire un test unitaire classique sur un agent. assert output == expected ne marche pas quand output varie à chaque run.

graph LR
    A[Même prompt] --> B[Run 1]
    A --> C[Run 2]
    A --> D[Run 3]
    B --> E["Résultat A"]
    C --> F["Résultat B"]
    D --> G["Résultat A'"]

En pratique :

• Les tests sur des agents doivent évaluer des propriétés (la réponse est-elle dans le bon format ? contient-elle les éléments attendus ?) plutôt que des valeurs exactes
• Un agent qui fonctionne 95 % du temps va planter les 5 % restants de façon imprévisible, pas toujours sur les mêmes inputs
• Débugger un comportement erratique demande de penser en distributions, pas en cas reproductibles

La non-déterminisme n’est pas un défaut à corriger. C’est une contrainte à intégrer dans la conception du système.

Il y a une conséquence mathématique souvent sous-estimée : le taux d’erreur se compose à chaque étape. Un agent à 95 % de précision par action, c’est 60 % de chances de finir correctement une tâche en 10 étapes. Sur 100 étapes, moins de 1 %. Ce n’est pas une question d’intelligence du modèle — c’est de la probabilité conditionnelle. Les agents longs échouent d’abord parce que les erreurs s’accumulent, pas parce que le modèle “ne comprend pas”.

Pourquoi les démos font rêver, et pourquoi elles mentent un peu

Une démo d’agent IA ressemble à un tour de magie parce qu’elle réunit les conditions parfaites : tâche clairement définie, données propres, contexte sans ambiguïté, résultat visible.

Dès qu’on sort de ce couloir, la complexité explose. Un endpoint /api/orders qui retourne parfois 200, parfois 422 selon un état de session implicite : l’agent va halluciner une interprétation cohérente et continuer. Une codebase avec des conventions non documentées : le modèle va appliquer les patterns les plus fréquents dans ses données d’entraînement, pas forcément les tiennes. Un système de fichiers avec des dépendances circulaires : bonne chance pour que l’agent les détecte sans outillage explicite.

La démo a été enregistrée après le run qui a marché. Les cinq runs précédents qui ont produit du code bugué, personne ne les montre.

Ce n’est pas une raison de rejeter l’outil. C’est une raison de ne pas construire des attentes sur des démos.

Pourquoi le dev Rust a partiellement raison

Le sceptique n’a pas tort sur le fond. Il pose juste la mauvaise question.

L’IA n’a pas de compréhension au sens humain du terme. Elle n’a pas de modèle mental du borrow checker, pas de représentation interne des règles d’ownership. Ce qu’elle a, c’est une capacité statistique fine à reconnaître des patterns de code Rust valide et à les reproduire dans des contextes similaires.

Sur du code standard et des bibliothèques populaires, ça marche souvent étonnamment bien. Sur du code qui sort des conventions, sur des contraintes implicites spécifiques à ton système, sur des interactions entre composants absents des données publiques, le modèle va produire quelque chose de plausible qui ne compile pas. Ou pire : qui compile, mais qui est incorrect.

Le vrai problème, c’est la surface d’erreur invisible. Quand un dev junior fait une erreur, il y a généralement un signal : une incompréhension visible, une question posée, un comportement qui trahit la confusion. Un LLM produit du code confiant quelle que soit la qualité de sa réponse. Il n’exprime pas le doute.

Ce que ça change vraiment pour un dev en 2026

L’IA agentique est un amplificateur. Ce qu’elle amplifie, c’est ta capacité à explorer et itérer dans les zones où tu as déjà un modèle mental solide.

Là où ça fait sens : les tâches répétitives à périmètre borné. Générer des tests unitaires sur du code bien typé, écrire du boilerplate de configuration, convertir des structures de données. Le modèle est dans son couloir, la fiabilité est haute.

L’exploration rapide d’une codebase inconnue aussi. Tu débarques sur un projet que tu ne connais pas, tu veux comprendre le module de paiement. Un agent avec accès aux fichiers te donne un point de départ en quelques secondes, pas infaillible, mais suffisant pour orienter la lecture.

Là où c’est risqué sans filet : le code critique sans revue humaine. Un diff de 200 lignes généré par un agent doit être relu avec le même niveau d’attention qu’un code écrit par un junior, peut-être plus, parce que la plausibilité syntaxique peut endormir la vigilance.

Et les systèmes avec des contraintes implicites fortes. Si les règles de ton domaine ne sont pas dans le contexte fourni à l’agent, il va improviser. Avec confiance.

Comprendre ces propriétés, c’est ce qui te permet de décider où intégrer l’IA et où ne pas le faire. Pas par idéologie, par pragmatisme.

Une des réponses concrètes à la non-déterminisme : le harness engineering. Pas tester l’agent, construire l’environnement dans lequel il opère. Quels outils il peut appeler, quelles contraintes bornent ses décisions, comment il valide son propre travail avant de te le rendre. L’équipe Codex d’OpenAI l’a formulé clairement : le travail d’ingénierie se déplace de l’écriture de code vers la conception du système autour de l’agent. J’ai fait une brève sur le sujet ici, avec les liens vers ce qu’Anthropic et OpenAI ont publié.