En bref : La plupart des projets d’IA en entreprise n’échouent pas parce que le modèle est faible. Ils échouent dans le dernier kilomètre : la connexion aux systèmes, aux données, aux droits d’accès et aux personnes réelles. Ce travail ne se fait pas à distance. Il faut des ingénieurs au sein de votre organisation jusqu’à ce que le système tourne au quotidien, et un plan pour qu’ils repartent.
1. La question qu’un dirigeant doit poser
Je regarde l’IA comme n’importe quel investissement. Est-ce rentable ? Quand ? Et à qui appartient le résultat une fois le prestataire parti ?
La plupart des pilotes d’IA ne passent pas ce test. Pas parce que la démo était mauvaise. La démo est en général la partie facile. Ils échouent parce que personne n’a budgété le travail entre « ça marche sur un portable » et « les gens l’utilisent chaque matin ».
Ce fossé a un nom dans le secteur. Palantir a bâti son modèle dessus il y a des années, avec des ingénieurs qui travaillent chez chaque client pour déployer et adapter ses plateformes. Aujourd’hui, des laboratoires d’IA comme OpenAI et Anthropic recrutent pour le même poste : le forward deployed engineer.
2. Où l’argent se perd
Le dernier kilomètre n’a rien de glorieux. Ce sont des droits d’accès que personne n’a documentés. Un champ du CRM qui veut dire trois choses différentes. Une équipe juridique qui doit valider les prompts. Un processus qui ne fonctionne que parce qu’une personne connaît les exceptions.
Rien de tout cela n’entre dans le périmètre du pilote. Le pilote se termine, la slide affiche « succès », et le budget de mise en production devient une nouvelle négociation. Les mois passent. Le sponsor change de priorités.
| Ce que suppose le plan projet | Ce qui se passe vraiment dans le dernier kilomètre | Qui paie |
|---|---|---|
| Les données sont prêtes une fois extraites | Accès, qualité et sens se négocient système par système | Votre équipe, en retards |
| L’intégration est une tâche technique | Elle est organisationnelle : responsables, validations, sécurité | Le sponsor, en crédibilité |
| Les utilisateurs adoptent un bon outil | Ils adoptent celui qui s’inscrit dans leur façon de travailler | Le business case |
| La passation est un document | La passation, ce sont des personnes qui l’ont construit elles-mêmes | Vous, à chaque changement |
3. Ce qui change avec des ingénieurs sur place
Un forward deployed engineer travaille là où se trouve le problème. Dans vos systèmes. Avec vos équipes. Jusqu’à ce que ça tourne.
Cela change trois choses qui comptent pour moi.
- Délai de valeur. La solution est construite dans l’environnement où elle vivra : pas besoin d’un second projet pour l’« industrialiser ».
- Risque. Intégration, droits d’accès et contrôles sont réglés dans les premières semaines, et non découverts après la réception du contrat.
- Propriété. Votre équipe construit en parallèle. À la fin de la mission, elle peut exploiter et faire évoluer ce qui a été construit.
Ce n’est pas bon marché à la semaine. Le travail est senior et opérationnel. Mais la comparaison qui compte n’est pas le tarif hebdomadaire. C’est le coût jusqu’à un système utilisé au quotidien. Un projet moins cher qui n’atteint jamais la production est l’option la plus coûteuse. Nous comparons les deux modèles dans notre guide de décision (EN).
4. Comment y recourir sans créer de dépendance
Les équipes intégrées ont leur propre piège : elles peuvent devenir permanentes. Avant de signer, exigez quatre choses.
- Un responsable nommé de votre côté, qui reprendra le système.
- Tout dans vos dépôts dès le premier jour : code, prompts, jeux d’évaluation et documentation.
- Un succès mesuré à l’usage, pas aux livrables : qui l’utilise, à quelle fréquence, avec quel résultat.
- Une sortie datée, avec des procédures d’exploitation et une passation que votre propre équipe a répétée.
Si un prestataire résiste sur l’un de ces quatre points, considérez-le comme un signal.
5. Questions fréquentes
Q : Qu’est-ce qu’un forward deployed engineer ?
R : Un ingénieur logiciel qui travaille au sein de l’organisation du client, sur ses systèmes et ses données, jusqu’à ce qu’une solution tourne en production. Le modèle a été popularisé par Palantir et il est aujourd’hui courant dans les entreprises d’IA.
Q : Est-ce la même chose que faire appel à un cabinet de conseil ?
R : Pas tout à fait. Un projet classique est souvent conçu et réalisé par l’équipe du cabinet, puis livré à la fin. Les forward deployed engineers construisent dans votre environnement, aux côtés de vos équipes, et restent jusqu’à ce que ça tourne.
Q : Combien de temps doit durer une telle mission ?
R : Le temps nécessaire pour qu’un premier cas d’usage tourne au quotidien et que votre équipe sache l’exploiter, avec une passation datée. L’absence de fin prévue est un signal d’alerte.
Q : Quand un modèle au forfait est-il préférable ?
R : Quand le périmètre est clair et autonome, que l’intégration est légère et que vous avez besoin d’un prix fixe. Tous les besoins d’IA ne demandent pas des ingénieurs sur place.
6. Conclusion
L’IA ne crée pas de valeur dans une démo. Elle en crée quand elle tourne au cœur de l’activité, chaque jour, entre les mains de ceux qui l’utilisent.
C’est ainsi que nous travaillons chez Thinkia : comme une seule équipe avec la vôtre, dans vos systèmes, avec la sortie prévue dès le départ. Si vous avez des pilotes qui ne sont jamais arrivés en production, voici notre approche (EN).