Un Forward Deployed AI Engineer répond d'une seule chose, du début à la fin : amener un processus précieux mais mal défini jusqu'en production, et démontrer qu'il a changé quelque chose. Toute la distinction tient là. Un ML engineer qui passe du temps avec les clients reste un ML engineer, et un solutions engineer qui écrit du code reste un solutions engineer. Ce qui change, c'est la personne qui répond du résultat.
Palantir a formulé la distinction il y a des années et elle tient toujours. Le développement produit, c'est une capacité pour beaucoup de clients. Le forward deployment inverse la logique.
Un client, beaucoup de capacités.
— Palantir, à propos du modèle forward deployed
Cette inversion explique pourquoi le premier mois compte autant. L'ingénieur mène de front la découverte du besoin, le développement applicatif, l'évaluation, l'intégration, la revue de sécurité et la conduite du changement. L'objectif n'est pas de produire un maximum de code, mais de lever les incertitudes dans le bon ordre.
Où passe réellement le mois
Environ 160 heures sur vingt jours ouvrés. Pour qui vient de la gestion de projet classique, un chiffre surprend : la construction représente à peine un tiers.
Les quatre semaines
- 01Semaine une
Comprendre et mesurer
- Transformer « nous voulons un agent IA » en un processus avec un responsable
- Observer les personnes qui font le travail, pas la description qu'en donne la direction
- Cartographier données, API, identités, rétention et frontières réseau
- Mesurer l'existant avant toute IA : délai, reprises, coût par dossier
- Réunir 30 à 100 cas représentatifs comme jeu de référence
- 02Semaine deux
Construire la tranche fine
- Poser le service, la CI/CD, le traçage et le versionnage des prompts
- Construire d'abord le connecteur le plus risqué, pas le plus simple
- Faire passer un vrai utilisateur d'un bout à l'autre du processus
- Mettre en place l'évaluation et nommer les erreurs par catégorie
- Montrer aux utilisateurs et couper tout ce qui ne bouge pas la mesure
- 03Semaine trois
Durcir et piloter
- Séparer les droits de lecture et d'écriture, aucun secret dans le code
- Ajouter la télémétrie : latence, coût, résultat, corrections manuelles
- Définir le comportement en cas d'échec : délais, repli, abstention, escalade
- Embarquer une cohorte volontairement réduite, 10 à 30 personnes
- Traiter de vrais dossiers et comparer à la mesure de la semaine une
- 04Semaine quatre
Production et bilan
- Corriger les classes d'erreur les plus fréquentes, pas les plus intéressantes
- Mise en production progressive avec retour arrière testé
- Nommer le responsable de l'exploitation et livrer le runbook
- Bilan : ce qui s'améliore, de combien, à quel coût
- Extraire le connecteur, le jeu d'évaluation et le schéma réutilisable
Pourquoi le premier jour ne sert pas à coder
L'échec le plus courant est le piège du prototype : une démonstration impressionnante sans mesure de départ ni hypothèse économique, impossible à généraliser parce que personne ne peut dire ce qu'elle a amélioré. Sans mesure du processus existant, il n'y a rien à comparer ensuite, et la décision de fin de mois repose sur l'enthousiasme plutôt que sur des preuves.
Les déploiements les mieux documentés partagent cette discipline. NTT DATA a d'abord consigné un point de départ : une analyse d'incident qui mobilisait cinq ingénieurs expérimentés pendant trois jours. La même analyse s'est ensuite exécutée en trente minutes. Rakuten avait mesuré vingt-quatre jours ouvrés jusqu'à la mise sur le marché d'une fonctionnalité avant que ce délai tombe à cinq.
Ce que mesurent ces chiffres compte autant que leur valeur : des résultats de processus, avec un avant et un après. Un décompte de tokens ou de prompts n'apprendrait rien ici. L'adoption se mesure séparément et volontairement, parce qu'un système qui réussit ses évaluations puis reste inutilisé a échoué sur le seul point qui importait.
Les modes d'échec à nommer tôt
| Risque | Signal précoce | Ce que nous faisons |
|---|---|---|
| Accès retardé | Un prototype existe mais aucun accès aux données réelles en fin de semaine une | Associer sécurité et IAM dès la découverte, construire entre-temps sur des jeux de test anonymisés |
| Piège du prototype | Enthousiasme pour la démonstration, aucune mesure de départ | Mesurer avant de construire et lier la décision de fin de mois à la comparaison avant-après |
| Périmètre qui gonfle | Trois directions dans le premier sprint | Un seul processus jusqu'à ce que la mesure bouge, avec une liste explicite de ce qui attend |
| Évaluation aveugle | La qualité se juge sur des prompts choisis | Verser les cas représentatifs au dépôt et les rejouer à chaque modification |
| Droits trop larges | L'agent peut modifier des systèmes sensibles | Moindre privilège, contrats d'outils typés, validation humaine pour les écritures à conséquence |
| Explosion des coûts | Belle démonstration, coût unitaire intenable | Suivre le coût par dossier réussi, pas par token |
| Transfert manqué | Seul l'ingénieur sait exploiter le système | Nommer les responsables tôt, livrer les runbooks, répéter un incident |
Ce que « terminé » veut dire au vingtième jour
Ce qui est remis est un dossier de preuves répondant à une question : ce mode de fonctionnement mérite-t-il d'être généralisé ? On y trouve un processus prioritaire avec sa mesure de départ, un jeu d'évaluation représentatif, une tranche fine prête pour la production, la télémétrie sur la qualité, le coût et l'usage, une vraie cohorte pilote, un dossier de mise en production, un runbook avec un responsable nommé et un bilan chiffré. L'agent lui-même en est la plus petite partie.
La question qui sépare une bonne mission d'une bonne démonstration
Le client peut-il exploiter ce système sans l'ingénieur qui l'a construit ? Si la réponse est non, le mois a produit une dépendance plutôt qu'une capacité, aussi bons que soient les indicateurs.
Un second livrable s'oublie facilement, et son absence se paie plus tard : le réutilisable. Un connecteur, un harnais d'évaluation, un schéma d'intégration, un retour pour le produit. Sans lui, chaque mission repart de zéro et le modèle se dégrade en développement sur mesure avec un plus bel intitulé de poste.
C'est la boucle que nous faisons tourner : comprendre sur place, construire sur place, mesurer sur place, puis extraire le schéma général pour que le déploiement suivant démarre plus loin.