L'adoption de l'IA n'a pas besoin de plus de formations en salle. Elle a besoin d'expertise Forward Deployed.

La plupart des entreprises n'ont plus besoin d'être convaincues que l'IA compte.

Les collaborateurs expérimentent avec ChatGPT, Claude, Copilot et des dizaines d'outils spécialisés. Les équipes de direction discutent de stratégies IA. Les organismes de formation remplissent les agendas de workshops, de sessions de prompt engineering et de journées d'inspiration.

Pourtant, quelques mois plus tard, beaucoup d'organisations butent encore sur la même question :

Où est l'impact mesurable ?

Le problème n'est pas nécessairement un manque de connaissance de l'IA. C'est l'écart entre savoir ce que l'IA peut faire et l'appliquer au travail, aux systèmes, aux contraintes et aux priorités spécifiques d'une organisation.

Cet écart est la raison pour laquelle je pense qu'une approche qui gagne du terrain dans l'industrie technologique va de plus en plus s'étendre au conseil et aux services professionnels : le Forward Deployed Engineering.

Le nom peut sembler technique. Le principe est remarquablement simple.

Au lieu d'expliquer l'IA aux gens à distance, placez quelqu'un doté d'une forte expertise IA et business à côté des personnes qui font le travail réel.

Comprendre le travail. Identifier les opportunités ensemble. Les prioriser avec le management. Puis construire.

Qu'est-ce que le Forward Deployed Engineering ?

Le Forward Deployed Engineering, ou FDE, s'est fait connaître à travers des entreprises technologiques comme Palantir et est aujourd'hui adopté beaucoup plus largement dans l'industrie de l'IA.

OpenAI, par exemple, a construit une organisation dédiée de Forward Deployed Engineering. Ses FDE travaillent aux côtés des clients sur la découverte, le cadrage technique, la conception du système, la construction et la mise en production, le succès étant mesuré par l'adoption et l'impact mesurable sur le workflow. EY a lancé ses propres rôles de Forward Deployed Engineer au Royaume-Uni et en Irlande en 2026, en les positionnant explicitement comme un moyen de faire passer les cas d'usage IA de l'expérimentation à la production.

L'important n'est pas l'intitulé de poste.

C'est le modèle opératoire.

Le conseil traditionnel sépare souvent l'analyse, la recommandation et l'implémentation. Une équipe analyse l'organisation, produit des recommandations, une autre équipe traduit ces recommandations en exigences, et quelqu'un finit par construire quelque chose.

Avec l'IA, cette séquence peut de plus en plus être compressée.

Vous pouvez observer un processus le matin, prototyper une alternative l'après-midi et laisser l'utilisateur la tester le lendemain.

Cela change ce à quoi un bon conseil devrait ressembler. (Pour une comparaison plus approfondie du FDE face aux agences, freelances et vendors, voir Qu'est-ce que le Forward Deployed Engineering ?)

L'adoption de l'IA commence sur le terrain

Prenez un commercial qui passe chaque matin à combiner des informations issues d'un ERP, d'e-mails et de tableurs avant de décider quels clients contacter.

Ou quelqu'un aux opérations qui lit manuellement les commandes PDF entrantes et reporte les informations dans un autre système.

Ou un collaborateur marketing qui recherche des prospects en ligne et prépare des prises de contact personnalisées.

Ou quelqu'un au prépresse qui passe des heures d'allers-retours avec les clients pour obtenir des fichiers au bon format.

Vous pouvez amener toutes ces personnes dans une salle de classe et leur enseigner le prompting, les agents et les grands modèles de langage.

Certains repartiront inspirés. Certains commenceront à utiliser les outils. Quelques-uns deviendront très bons.

Mais vous n'avez toujours redessiné aucun de ces workflows.

Une approche Forward Deployed commence ailleurs.

Asseyez-vous à côté du collaborateur et regardez le travail se faire.

De quelles informations a-t-il besoin ?

D'où viennent ces informations ?

Quelles décisions exigent du jugement ?

Quelles parties sont répétitives ?

Où copie-t-il et colle-t-il ?

Quelles exceptions compliquent ce processus apparemment simple ?

Quels systèmes sont impliqués ?

Quelles données sont sensibles ?

Qu'est-ce qui fait qu'un client ou un collègue appelle cette personne parce que « elle seule sait comment ça marche » ?

Ces questions révèlent des opportunités qui émergent rarement d'une session de formation IA ou d'un workshop de direction seuls.

Et il y a un autre avantage important : le collaborateur apporte quelque chose que l'expert IA n'a pas.

L'expertise métier.

La personne qui effectue le travail chaque jour comprend les exceptions, le comportement des clients, les décisions historiques, les mauvaises données et le contexte organisationnel. L'expert IA comprend ce qui vient de devenir techniquement possible.

L'implémentation IA fonctionne le mieux quand vous réunissez ces deux formes d'expertise.

Un autre modèle pour l'implémentation IA

Chez ScopeRight, le modèle que nous développons est délibérément léger.

Il ne commence pas par un programme de transformation de six mois.

Il commence par un court intake pour comprendre la stratégie, les objectifs, les systèmes et la maturité IA actuelle de l'entreprise.

Puis le vrai travail commence.

1. L'intake : comprendre le contexte stratégique

Avant de chercher des cas d'usage IA, il faut comprendre ce que l'organisation essaie d'accomplir.

La priorité est-elle la croissance ?

L'amélioration des marges ?

La réduction de la charge administrative ?

Passer à l'échelle sans augmenter les effectifs ?

Améliorer le service client ?

Raccourcir les délais ?

Réduire la dépendance à une expertise rare ?

Les opportunités IA ne doivent pas exister isolément de ces priorités.

L'intake crée donc un cadre stratégique. Il identifie aussi les contraintes de gouvernance évidentes : données sensibles, exigences de sécurité, choix technologiques existants et initiatives déjà en cours.

Sans cette étape, les programmes IA se transforment facilement en une collection d'expérimentations intéressantes.

2. Une demi-journée aux côtés des collaborateurs clés

Ensuite, un expert IA passe un temps concentré avec un petit nombre de collaborateurs occupant des rôles stratégiquement pertinents.

Pas en les interviewant depuis une salle de réunion.

En regardant réellement comment le travail se fait.

Une demi-journée peut déjà révéler étonnamment beaucoup quand l'objectif n'est pas de documenter chaque processus mais d'identifier où l'IA pourrait fondamentalement changer la façon dont le travail s'effectue.

L'expert IA combine la compréhension du business avec assez de profondeur technique pour reconnaître immédiatement différents patterns de solution.

Certaines opportunités ne demandent rien de plus qu'un usage correct d'un outil IA existant.

D'autres exigent de connecter des systèmes existants.

Certaines peuvent être résolues par un agent configurable.

D'autres justifient une petite application sur mesure.

Et parfois, la bonne conclusion est de ne rien construire, parce que Microsoft, Salesforce, Adobe ou une autre plateforme résoudra probablement le problème nativement.

L'indépendance compte ici.

L'objectif n'est pas de vendre une plateforme IA en particulier.

C'est de trouver la meilleure façon de créer de la valeur.

3. Construire la longlist d'opportunités

Le livrable n'est pas immédiatement une énorme feuille de route IA.

C'est d'abord une longlist pratique.

Pour chaque opportunité, vous voulez comprendre au minimum :

• Quel problème résolvons-nous ?
• Qui subit le problème ?
• À quoi ressemble le workflow actuel ?
• Qu'est-ce que l'IA pourrait changer ?
• Quelle pourrait être l'ampleur de l'impact ?
• Quelle est la difficulté de l'implémentation ?
• Quelles données et quels systèmes sont nécessaires ?
• Quelles sont les implications de sécurité ou de gouvernance ?
• Faut-il acheter, configurer, construire ou attendre ?
• À quoi ressemblerait la plus petite version utile ?

Cette dernière question est particulièrement importante.

Parce qu'au lieu de définir immédiatement la solution finale, vous définissez un Minimum Viable Agent — un MVA.

Du cas d'usage au Minimum Viable Agent

Le MVA est à l'implémentation IA ce que le MVP est devenu au développement produit.

C'est la plus petite version d'un workflow doté d'IA capable de prouver si l'idée crée une valeur réelle.

Imaginez une organisation commerciale qui ambitionne de créer un « assistant commercial IA ».

Cela pourrait devenir un projet massif.

Intégration CRM. Intégration e-mail. Recherche de comptes. Lead scoring. Préparation des rendez-vous. Suivi. Forecasting. Création de propositions.

À la place, le premier MVA pourrait simplement faire ceci :

Chaque matin, analyser les informations clients et prospects disponibles et donner à chaque commercial dix comptes à contacter aujourd'hui, avec la raison et une suggestion de message d'ouverture.

C'est assez étroit pour être construit.

Et assez précis pour être mesuré.

Le commercial l'utilise-t-il ?

L'information est-elle pertinente ?

Gagne-t-il du temps ?

L'activité augmente-t-elle ?

Cela mène-t-il à plus de conversations ?

Si la réponse est oui, étendez-le.

Si la réponse est non, vous avez appris quelque chose de précieux sans dépenser six mois et un gros budget de transformation.

4. Le debrief avec le management : sélectionner ce qui compte vraiment

La longlist revient ensuite au management.

Cette étape est critique parce que la découverte bottom-up sans priorisation top-down crée un autre problème familier : des dizaines d'idées IA intéressantes qui se disputent l'attention.

Le management doit faire des choix.

Quelles opportunités soutiennent notre stratégie ?

Où est la valeur économique ?

Quels problèmes sont réellement douloureux ?

Où pouvons-nous apprendre vite ?

À quoi ne devons-nous pas encore toucher pour des raisons de sécurité, de qualité des données ou de dépendances ?

Quelles initiatives devraient simplement utiliser un produit sur étagère ?

Et quels workflows sont assez différenciés pour justifier du sur-mesure ?

Le résultat devrait être un petit nombre de MVA délibérément sélectionnés, pas un catalogue d'expérimentations IA possibles.

Cela crée l'alignement stratégique avant que le développement commence. (C'est exactement ce qu'un workshop de priorisation et de cadrage des cas d'usage IA est conçu pour produire.)

5. Construire en sprints MVA courts

Une fois un MVA sélectionné, le modèle Forward Deployed ne produit pas un énième deck de recommandations.

Il construit.

Idéalement dans un sprint mesuré en semaines plutôt qu'en mois — la forme d'un Sprint Minimal Viable Agent.

Le collaborateur qui a initialement montré le processus reste impliqué tout au long de ce sprint. Il teste les premières versions, explique les exceptions, remet en question les hypothèses et aide à façonner la solution.

Le MVA évolue donc dans l'environnement où il sera finalement utilisé.

Cela a plusieurs conséquences importantes.

L'applicabilité est intégrée au processus, parce que la solution naît du travail réel plutôt que d'un cas d'usage théorique.

L'alignement stratégique est intégré, parce que le management choisit quelles opportunités méritent un investissement.

Les résultats arrivent tôt, parce que chaque opportunité sélectionnée doit devenir quelque chose d'utilisable plutôt que rester une recommandation.

Et peut-être le plus important :

La formation se fait automatiquement.

La meilleure formation IA ne ressemble peut-être pas à une formation

C'est l'un des aspects du modèle que je trouve les plus intéressants.

Les entreprises estiment, à juste titre, qu'elles doivent former leurs équipes à l'IA.

Mais envoyer vingt collaborateurs en salle pour une journée a un coût substantiel.

Vingt personnes passant huit heures en formation représentent 160 heures de travail avant que quoi que ce soit ait changé opérationnellement.

Et le transfert de la connaissance générale au comportement quotidien est incertain.

L'implémentation embarquée inverse ce modèle.

Au lieu d'enseigner d'abord aux gens tout ce que l'IA pourrait faire, vous leur enseignez en résolvant un problème qui compte pour eux.

Un collaborateur travaille aux côtés de l'expert IA.

Il apprend pourquoi une approche fonctionne et une autre non. Il voit ce que le prompting peut accomplir, ce qu'est un agent, où les données deviennent importantes, pourquoi les intégrations comptent, quelles contraintes de sécurité doivent être prises en compte et quand un développement sur mesure a du sens.

Plus important encore, il commence à apprendre à reconnaître lui-même de nouvelles opportunités IA.

Cela crée un type de capacité très différent.

L'objectif n'est pas que tout le monde devienne spécialiste de l'IA.

C'est que les collaborateurs deviennent meilleurs pour combiner leur expertise métier avec une compréhension de ce que l'IA sait désormais faire.

C'est la compétence dont les organisations ont réellement besoin.

De la formation IA à la transformation continue

Il y a une autre raison pour laquelle le modèle de formation traditionnel est en difficulté.

L'IA change trop vite.

Un cursus construit il y a six mois peut déjà omettre des capacités importantes. Des produits qui exigeaient du développement sur mesure l'an dernier peuvent devenir des fonctionnalités standard cette année. Les coûts baissent. Les modèles s'améliorent. Les interfaces changent. De nouvelles capacités agentiques apparaissent.

La capacité IA ne peut donc pas être traitée comme quelque chose qu'une organisation apprend une fois.

Elle a besoin d'une boucle de feedback.

Observer.

Identifier les opportunités.

Prioriser.

Déployer.

Mesurer.

Apprendre.

Puis recommencer.

Certaines entreprises développeront à terme cette capacité en interne.

D'autres continueront à combiner des experts métier internes avec des experts IA externes indépendants qui apportent périodiquement la perspective technologique la plus récente.

Dans les deux cas, la capacité elle-même devient permanente.

Cela va changer le conseil

Je m'attends à ce que ce modèle influence le conseil bien au-delà de l'IA.

Pendant des décennies, l'économie du conseil reposait en partie sur la rareté : l'expertise était chère, l'analyse prenait du temps, et l'implémentation exigeait de grandes équipes.

L'IA change ces contraintes.

De petites équipes dotées d'un solide jugement business, d'une connaissance métier profonde et de capacités techniques augmentées par l'IA peuvent de plus en plus passer du problème au prototype à une vitesse extraordinaire.

La distinction entre consultant en stratégie, technologue et spécialiste de l'implémentation commence donc à s'estomper.

Cela ne rend pas la stratégie moins importante.

Cela rend la distance entre stratégie et exécution beaucoup plus courte.

Le consultant du futur passera peut-être moins de temps à produire des recommandations sur ce qu'une entreprise devrait faire et plus de temps à travailler aux côtés des collaborateurs pour déterminer, construire et tester comment l'entreprise pourrait réellement fonctionner différemment.

Le Forward Deployed Engineering est un nom pour ce changement.

Pour les PME, je soupçonne que la terminologie comptera finalement moins que la promesse :

Amener l'expertise IA au travail, plutôt que d'amener les équipes dans une salle de classe IA.

Partir des processus réels.

Combiner expertise métier et expertise IA.

Aligner les opportunités avec le management.

Construire la plus petite solution utile.

Mesurer ce qui se passe.

Et rendre l'organisation plus intelligente ce faisant.

Voilà, à mes yeux, un chemin bien plus convaincant de l'ambition IA à l'impact IA.

---

Curieux de voir ce qu'une approche Forward Deployed ferait émerger dans votre organisation ? Réservez un intake gratuit de 30 minutes. Nous vous aiderons à trouver les workflows où l'expertise IA à côté du travail — pas dans une salle de classe — crée un impact mesurable.