Pourquoi les pilotes d'IA calent (et comment l'éviter)

Écrit par la rédaction · 12 novembre 2026 · Mis à jour le12 novembre 2026

Un pilote d'IA cale le plus souvent faute de propriétaire côté métier, parce qu'il tourne sur des données de démonstration plutôt que sur les vrais documents, sans validation par une personne de l'entreprise et sans suivi après la mise en route. Un ingénieur forward deployed travaille chez le client, avec ses vrais fichiers et ses vraies équipes, ce qui supprime ces quatre causes sans garantir pour autant le résultat : il faut encore quelqu'un côté métier pour valider.

Le pilote marche en démonstration, tout le monde applaudit, puis rien ne se passe. Trois mois plus tard, personne ne s’en sert. Cet article liste les causes concrètes de ce scénario et ce qu’un ingénieur qui travaille dans l’entreprise change. Nous ne donnons aucun chiffre sur la fréquence du phénomène : nous n’avons pas lu de source primaire qui le mesure.

Pourquoi un pilote d’IA cale-t-il ?

Quatre causes reviennent, et elles se combinent.

Personne, côté métier, n’en est propriétaire

Le pilote naît souvent à la direction informatique ou à l’innovation. Le service qui devrait s’en servir (devis, support, bureau d’études) n’a pas demandé l’outil et n’a personne pour dire si la réponse est bonne. Sans propriétaire, personne ne tranche quand l’agent se trompe, et personne ne réclame la version suivante.

Le pilote tourne sur des données qui ne ressemblent pas aux vraies

Quelques documents propres, choisis pour la démonstration, donnent de belles réponses. Les vrais dossiers contiennent des scans, des versions en double, des conventions de nommage que personne n’a écrites. Anthropic décrit le piège côté test : ses ingénieurs recommandent de bâtir les tâches d’évaluation à partir de vrais échecs, et rappellent que cela garantit un jeu de tests fidèle à l’usage réel. Un pilote qui n’a jamais vu un document difficile n’a rien prouvé.

Aucune personne de l’entreprise ne valide

Un agent qui prépare une réponse ou un document peut se tromper. Anthropic précise que l’autonomie d’un agent entraîne des coûts plus élevés et des erreurs qui peuvent s’accumuler, et recommande des tests poussés en environnement isolé ainsi que des garde-fous. Quand personne ne relit avant l’envoi, la première erreur visible sert d’argument pour arrêter le projet.

Personne ne suit ce qui se passe après la mise en route

Anthropic écrit que sans évaluations, les équipes se retrouvent dans une boucle réactive : elles attendent les plaintes, corrigent, et espèrent que rien d’autre n’a cassé. Il ajoute que les évaluations deviennent plus difficiles à bâtir plus on attend. Un pilote livré sans suivi se dégrade en silence, jusqu’au jour où l’équipe métier a cessé de lui faire confiance.

Que change un ingénieur forward deployed ?

Forward deployed désigne un ingénieur envoyé chez le client plutôt que cantonné à son propre bureau. Le mot vient de l’idée d’être déployé au plus près du terrain.

• Les vraies données dès le début. L’agent est branché sur les dossiers réels, avec leurs défauts. Les cas difficiles apparaissent la première semaine, pas après la signature.
• Un propriétaire nommé. Un ingénieur sur place demande qui, dans l’entreprise, jugera les réponses. Si la réponse est « personne », le projet attend.
• Des échecs transformés en tests. Quand un utilisateur signale une erreur, l’ingénieur la voit, la corrige et la garde comme cas de contrôle, ce qui reprend la méthode décrite par Anthropic.
• Un suivi qui continue. L’ingénieur reste l’interlocuteur après la mise en service.

La limite est réelle : un ingénieur, même présent, ne remplace pas la personne du métier qui valide. Si l’entreprise ne libère personne pour relire les premières sorties, le pilote cale de la même façon.

À quoi ressemble un pilote qui a de bonnes chances de tenir ?

Quelques conditions se vérifient avant d’écrire la moindre ligne de code.

• Le nom de la personne du métier qui jugera les réponses est connu, et son temps de relecture est réservé dans son agenda.
• Les documents utilisés sont les vrais, y compris les plus désordonnés, et pas une sélection préparée pour l’occasion.
• Il existe une première série de cas de contrôle. Anthropic estime que 20 à 50 tâches simples tirées de vrais échecs forment un bon départ, et que les évaluations deviennent plus difficiles à construire quand on attend.
• Quelqu’un regarde l’usage réel après le lancement. Anthropic décrit ce suivi comme un complément des évaluations automatiques : il révèle le comportement des utilisateurs à grande échelle et attrape des problèmes que les tests synthétiques manquent.
• On sait à l’avance ce que l’agent n’a pas le droit de faire seul, par exemple envoyer un document à un client.

Aucune de ces conditions ne demande un budget particulier. Elles demandent des décisions prises tôt, par des gens de l’entreprise, et c’est là que la présence d’un ingénieur sur place sert le plus : il pose les questions avant que le pilote ne commence.

Et chez nous ?

Nous publions ce blog. Nous sommes trois ingénieurs de Télécom Paris spécialisés en IA, en forward deployed. Le premier appel dure 30 minutes, il est offert et sans engagement. Vous nous ouvrez l’accès à vos outils en deux clics, sans mot de passe, et deux semaines après l’appel un premier agent tourne. Ensuite vous avez un interlocuteur dédié.

Rien ne part sans la validation d’une personne de votre entreprise : c’est une règle de notre mode de fonctionnement, pas une option. Les agents citent leurs sources, de sorte que la personne qui valide peut vérifier d’où vient chaque réponse. Voir la page sur la transformation IA en entreprise et celle sur l’audit IA.