Vous avez peut-être déjà payé pour un audit IA. Trente pages, une feuille de route, des cas d’usage classés par ordre de priorité. Le document était juste. Un an plus tard, il dort dans un dossier partagé et vos processus n’ont pas bougé d’un millimètre. Ce décalage entre le diagnostic et la mise en service, nous le rencontrons plusieurs fois par trimestre, et il vient rarement de la qualité du rapport. Il vient de ce qui n’a pas eu lieu après. Le métier qui répond exactement à ce vide s’est imposé aux États-Unis en dix-huit mois, et parler de FDE Forward Deployed Engineer en PME paraît encore incongru en France. C’est pourtant là que le modèle a le plus de sens.
Un métier né chez Palantir, propulsé par la vague des agents
Le principe vient de Palantir. Plutôt que de vendre une licence et de laisser le client se débrouiller avec l’intégration, l’entreprise envoyait ses ingénieurs s’installer chez lui. Dans ses bureaux, dans ses équipes, sur ses vraies données. OpenAI et Anthropic ont repris la méthode pour déployer leurs modèles en entreprise. Salesforce a annoncé vouloir constituer une équipe de mille profils de ce type.
Le marché de l’emploi donne la mesure du phénomène. Entre janvier et septembre 2025, les offres publiées pour ce poste ont progressé de plus de 800 % d’après une analyse conjointe d’Indeed et du Financial Times. Les rémunérations affichées chez les éditeurs américains dépassent couramment 350 000 dollars annuels. Un métier que presque personne ne connaissait il y a trois ans est devenu l’un des plus disputés de la filière.
Pourquoi maintenant ? Parce que les agents ont déplacé la difficulté. Faire tourner un modèle de langage est devenu trivial, quelques lignes de code et un abonnement suffisent. Le vrai obstacle s’est déporté ailleurs, du côté du branchement sur un ERP installé en 2011, de règles tarifaires que personne n’a jamais écrites, de fichiers Excel officieux qui font tourner un service entier, et d’utilisateurs qui ont déjà vu passer trois outils abandonnés en cinq ans. Aucun de ces problèmes ne se résout depuis une salle de réunion.
Ce qui sépare cet ingénieur d’un consultant ou d’un intégrateur
La distinction tient en une phrase. Le FDE porte la responsabilité du résultat en production, pas celle du livrable intermédiaire.
Un consultant IA produit un diagnostic et une trajectoire. Son travail s’arrête, en général, là où commence le vôtre. Un intégrateur livre un périmètre défini au contrat, et ce qui sort du périmètre sort aussi du budget. Un développeur interne connaît la maison mieux que quiconque, mais maîtrise rarement les modèles, les agents, l’évaluation des réponses et les garde-fous associés. Chacun de ces métiers est utile. Aucun ne couvre le trajet complet entre une idée validée et un flux que vos équipes utilisent tous les matins sans y penser.
Concrètement, l’ingénieur embarqué passe ses journées à faire des choses assez peu spectaculaires. Observer un poste de travail pendant deux heures. Comprendre pourquoi l’assistante commerciale recopie à la main une donnée déjà présente dans l’ERP. Écrire le connecteur qui manque. Tester avec trois utilisateurs, découvrir que la moitié des demandes contiennent des références obsolètes, ajuster. Mesurer un indicateur convenu à l’avance. Former la personne qui reprendra le sujet après son départ.
- Il cadre un cas d’usage rentable au lieu d’en lister quinze.
- Il raccorde les outils déjà payés, messagerie, ERP, CRM, base documentaire, fichiers métier.
- Il construit ce qui manque, agent, recherche documentaire, automatisation, supervision.
- Il installe une validation humaine partout où l’erreur coûte cher.
- Il transfère la maîtrise, documentation comprise, pour ne pas devenir indispensable.
À quoi ressemble une intervention dans un négoce industriel
Prenons un cas représentatif du type de chantier que nous menons. Un négociant en composants industriels installé à Longpont-sur-Orge, une soixantaine de salariés, reçoit chaque jour une quarantaine de demandes de prix par courriel. Le circuit est toujours le même. Un commercial ouvre le message, cherche les références dans l’ERP, vérifie la disponibilité, interroge parfois le fournisseur sur un délai, puis rédige sa réponse. Comptez vingt à trente minutes par demande quand tout se passe bien.
Le délai de réponse moyen s’établit autour de deux jours. Un concurrent qui répond en quatre heures emporte l’affaire avant même que le devis ne parte. Le dirigeant le sait. Il a demandé un audit, obtenu une recommandation d’automatisation du processus de devis, et rien ne s’est passé, parce que personne n’a voulu mettre les mains dans un ERP vieillissant dont le connecteur officiel n’existe plus.
Une intervention embarquée démarre autrement. Première semaine sur site, à regarder travailler deux commerciaux et à relever ce qui bloque vraiment, les références mal orthographiées dans les demandes clients, les remises négociées qui ne figurent nulle part, les trois grands comptes dont les conditions sont dans la tête du directeur commercial. Semaines suivantes, on raccorde la boîte partagée, le catalogue produits et les niveaux de stock. L’agent lit la demande, propose les références correspondantes, prépare un brouillon de devis et l’ouvre dans le CRM. Le commercial garde la main sur le prix, la marge et le délai, systématiquement.
Sur ce type de chantier, l’ordre de grandeur observé se situe entre six et dix semaines pour un premier flux réellement utilisé, et le délai de réponse tombe généralement sous la demi-journée. Ce n’est pas de la magie. C’est du raccordement patient, avec une part de travail ingrat qu’aucune démonstration commerciale ne montre jamais.
Pourquoi votre PME ne recrutera pas ce profil
Autant le dire franchement. Un Forward Deployed Engineer dans une PME de soixante personnes, recruté en interne, est une mauvaise idée dans la quasi-totalité des cas.
Le profil est rare et cher, disputé par des éditeurs qui alignent des rémunérations sans rapport avec vos grilles. Même en supposant que vous trouviez la personne et que vous acceptiez le coût, une entreprise de cette taille n’a pas douze mois de travail à ce niveau d’intensité. Vous auriez un ingénieur très qualifié, très bien payé, occupé à mi-temps sur de la maintenance dès le troisième mois. Et le jour où il part, la connaissance part avec lui.
Ce qui se transpose, en revanche, c’est la méthode. L’engagement sur le résultat en production plutôt que sur le rapport. La présence sur site, dans les équipes, sur les vraies données. Le transfert de compétences organisé dès le départ vers un référent interne, et c’est d’ailleurs la raison pour laquelle nous insistons autant sur l’intérêt de désigner un référent IA dans l’entreprise avant même de lancer le premier chantier. Le modèle vaut par sa posture, pas par la fiche de poste.
Les compétences qui font vraiment la différence
Le socle technique est exigeant mais assez balisé. Modèles de langage, agents, recherche documentaire sur base interne, évaluation des réponses, garde-fous, intégrations par API, bases de données, authentification. Beaucoup de développeurs sérieux montent en compétence là-dessus en quelques mois.
Ce qui se transmet moins facilement est ailleurs. Savoir écouter un chef d’atelier qui explique mal un problème qu’il connaît parfaitement. Reconnaître qu’un cas d’usage brillant sur le papier ne survivra pas au premier mois d’usage réel, et le dire avant d’avoir dépensé le budget. Accepter qu’une automatisation à 70 % validée par un humain vaut mieux qu’une automatisation à 100 % que personne n’ose activer. Tenir la conversation avec un dirigeant, une équipe terrain et un prestataire informatique dans la même réunion, sans perdre l’un des trois.
Notre conseil, quand vous évaluez un prestataire sur ce terrain, demandez-lui de vous raconter une mission qui s’est mal passée. La réponse vous en apprendra davantage que n’importe quelle liste de références.
Transposer le modèle à l’échelle d’une entreprise de taille moyenne
La forme qui fonctionne chez nos clients tient en trois temps, avec une porte de sortie à chaque étape.
Un cadrage court d’abord, quelques jours, pour choisir un processus dont la rentabilité se démontre et écarter les autres. On y regarde l’état réel des données, le risque juridique, la charge des équipes et l’indicateur qui servira de juge. Il arrive que ce cadrage débouche sur une recommandation de ne rien lancer cette année. C’est un résultat acceptable, et moins coûteux qu’un projet mené sans conviction.
Vient ensuite un sprint d’embarquement, six à huit semaines, pendant lesquelles on construit et on raccorde un premier flux utilisable. Pas une maquette. Un circuit branché sur vos outils, testé par vos utilisateurs, avec ses règles de validation et sa mesure. Cette étape suppose une présence régulière sur site, et vous verrez passer des semaines où le travail visible se résume à comprendre pourquoi un export produit deux formats de date différents.
Le troisième temps est l’accompagnement dans la durée, étendre à un deuxième processus, corriger ce que l’usage révèle, former les équipes, transférer la maîtrise. La méthode complète d’intégration de l’IA en entreprise et le panorama des usages par métier détaillent ce que recouvre chacune de ces phases selon votre secteur.
L’intérêt du modèle du FDE en PME ne tient pas à l’anglicisme, qui vieillira sans doute mal. Il tient à un déplacement de la responsabilité, celui qui conçoit reste jusqu’à ce que le système fonctionne sur vos données, avec vos équipes, dans vos outils. Si vous avez un rapport d’audit qui dort quelque part et un processus qui vous coûte visiblement du temps, c’est exactement le point de départ d’un échange avec MINOBIA.
Questions fréquentes
Faut-il vraiment que l’ingénieur vienne sur place ?
Pour la phase d’observation et les tests utilisateurs, oui, quelques journées font gagner des semaines. Le développement et le raccordement se mènent ensuite très bien à distance.
Mon système d’information est ancien, est-ce éliminatoire ?
Rarement. Un ERP sans interface moderne se contourne par des exports, un accès en lecture à la base ou un dépôt de fichiers. Ce qui bloque vraiment, c’est l’absence de données fiables, pas l’ancienneté du logiciel.
Quelle différence avec une agence qui livre une automatisation ?
L’engagement porte sur l’usage réel et sur un indicateur mesuré, pas sur la livraison d’un périmètre. Une automatisation livrée que personne n’utilise est un échec dans ce modèle, même si le contrat est rempli.
Combien de temps avant de voir un effet ?
Comptez six à dix semaines pour un premier flux en service sur un processus bien choisi. Les chantiers annoncés à deux semaines produisent des démonstrations, pas des outils de travail.
Et si le cadrage conclut qu’il ne faut rien faire ?
Cela arrive, et c’est une bonne nouvelle. Mieux vaut quelques jours de cadrage qu’un projet de plusieurs mois lancé sur un processus instable ou sur des données que personne ne tient à jour.
À propos de l’auteur
Joël Obitz est entrepreneur et fondateur de MINOBIA, cabinet spécialisé dans l’intégration stratégique de l’intelligence artificielle au sein des PME et ETI. Fort de 20 ans d’expérience dans le B2B industriel, il accompagne les entreprises dans leur transformation numérique, avec une approche directe, pragmatique et orientée résultats.
Contactez-nous : contact@minobia.ai
Suivez-nous sur LinkedIn et Facebook
MINOBIA – Activateur France Num https://www.francenum.gouv.fr/activateurs/minobia
