La difficulté n’est pas le modèle. Les modèles disponibles aujourd’hui sont largement suffisants pour la quasi-totalité des besoins réels. Ce qui fait échouer les projets, ce sont les outils mal décrits, le contexte mal géré, les permissions trop larges et l’absence de mesure. Ce sont des problèmes d’ingénierie classique — et ils se traitent avec des méthodes d’ingénierie classique.

Les 15 pièges les plus fréquents

1. L’agent là où un script suffisait

Un agent à 40 tours qui fait ce qu’une fonction de 30 lignes faisait mieux. Si l’organigramme des étapes peut être dessiné à l’avance, c’est un workflow qu’il faut construire.

2. Le prompt système obèse

8 000 tokens de prompt système, ajoutés cas par cas au fil des bugs. Chaque fois qu’on ajoute une règle au prompt, se demander si un garde-fou dans le code ne serait pas plus fiable. Une règle dans le prompt est une suggestion ; une règle dans le code est une garantie.

3. Le catalogue d’outils pléthorique

45 outils — l’agent choisit mal. Au-delà d’une vingtaine d’outils, la précision de sélection chute. Regrouper au niveau de l’intention métier (“rechercher_client” plutôt que trois outils SQL séparés), ou déléguer à des sous-agents spécialisés.

4. Les erreurs opaques

L’agent boucle sur le même appel qui échoue parce que l’outil renvoie “Error: 400” sans indication. Chaque message d’erreur doit dire ce qui ne va pas et ce qu’il faut faire à la place. C’est le meilleur rapport effort/fiabilité de toute la liste.

5. L’absence de budget

Une facture inattendue, ou un agent qui tourne depuis six heures. Poser systématiquement : limite de tours, de tokens, de durée et de coût — avec production d’un résultat partiel au dépassement.

6. Le contexte non géré

L’agent oublie l’objectif, se répète, se contredit à partir du vingtième tour. Solution : compaction structurée, externalisation vers fichiers, sous-agents à contexte isolé.

7. Le multi-agent prématuré

Cinq agents pour une tâche qu’un seul traiterait, coût multiplié par six, débogage impossible. Commencer mono-agent. Ne découper que lorsqu’on peut nommer précisément le gain attendu.

8. La confirmation cosmétique

L’opérateur approuve trente actions par heure sans lire, sur la base des résumés de l’agent. Moins de confirmations, mais réelles, affichant l’action brute. Automatiser le reste par politique.

9. L’absence d’évaluation

“Ça marchait avant” — sans savoir quand ni pourquoi ça a cessé. Dix cas de test en intégration continue dès la première semaine. C’est une journée de travail qui en économise dix.

10. Les permissions par défaut

L’agent tourne avec le compte d’administration parce que “c’était plus simple pour tester”. Une permission temporaire de développement devient permanente en production. Identité par agent, portée minimale, dès le prototype.

11. Le bac à sable inexistant

L’agent exécute du code directement sur l’hôte. Conteneur non privilégié sans accès réseau, dès le premier jour. Ce n’est pas une optimisation ultérieure.

12. Le prototype promu en production

Le script d’essai du vendredi tourne encore six mois plus tard, avec la clé d’API en clair dans le fichier. Poser une frontière explicite entre expérimentation et production, avec une liste de contrôle de passage.

13. La confiance dans les citations

L’agent cite des références, des CVE ou des articles qui n’existent pas. Vérification programmatique de l’existence des références citées — pas une instruction dans le prompt.

14. La dépendance non versionnée

Le comportement change du jour au lendemain sans modification du code — mise à jour du modèle en amont ou d’un serveur MCP tiers. Épingler les versions de modèles, rejouer l’évaluation avant toute montée de version.

15. L’oubli de l’humain

Un agent techniquement correct que personne n’utilise. Les agents qui réussissent automatisent une corvée identifiée — un travail répétitif que quelqu’un fait aujourd’hui et qui lui coûte du temps. Pas une capacité impressionnante qu’on déploie en espérant que quelqu’un s’en servira.

La checklist de mise en production

À parcourir avant tout passage en production. Les points marqués (B) sont bloquants.

Fonctionnel

(B) Le périmètre de l’agent est écrit noir sur blanc : ce qu’il fait, ce qu’il ne fait pas
(B) Le critère de terminaison est explicite
La politique d’échec est définie : combien de tentatives, quand escalader
Le comportement en cas de dépassement de budget produit un résultat partiel exploitable

Qualité

(B) Jeu de cas de test (minimum 10) exécuté en intégration continue
Assertions programmatiques sur les sorties critiques
Seuils de régression sur le coût et le nombre de tours
Évaluation rejouée avant chaque changement de modèle

Coûts

(B) Plafond de coût par exécution
Plafond par utilisateur et par période
Mise en cache des préfixes activée et taux mesuré
Étiquetage permettant d’attribuer chaque euro dépensé

Sécurité

(B) Identité dédiée à l’agent, portée minimale
(B) Aucun secret dans le prompt ou le contexte
(B) Bac à sable non privilégié pour toute exécution de code
(B) Accès réseau refusé par défaut
Liste d’outils autorisés, refus par défaut
Actions destructrices derrière confirmation affichant l’action brute
Serveurs MCP tiers relus et épinglés

Exploitation

(B) Traces complètes par tour, avec coût
(B) Arrêt d’urgence testé, y compris par révocation d’identifiants
Journal d’audit immuable, hors de portée de l’agent
Alertes sur taux d’échec, dérive de coût, actions bloquées
Procédure d’incident documentée

Conformité

Base légale identifiée si données personnelles
Inscription au registre des traitements si applicable
Pas de décision automatisée à effet significatif sans intervention humaine
Localisation des données vérifiée contre l’exigence contractuelle

Les trois idées à retenir

La difficulté n’est pas le modèle. C’est le harnais — les outils, le contexte, les permissions, l’observabilité.

Le rayon d’impact est le seul chiffre qui compte vraiment. Avant de se demander ce que l’agent peut faire, se demander ce qu’il pourrait faire s’il était détourné.

Commencer petit et mesurer. Un agent qui automatise une corvée identifiée, avec dix cas de test et un plafond de coût, vaut infiniment mieux qu’une architecture multi-agent impressionnante que personne n’utilise.

Passer du prototype à la production est le moment critique. Pour un accompagnement sur la mise en place sécurisée de vos agents IA, demandez un diagnostic.