Mettre en service une décision que d’autres ont prise
Le consultant en mise en œuvre intervient après la décision. Quelqu’un a choisi de construire une chose, un budget existe, et son travail consiste à la faire exister et fonctionner à l’intérieur de l’organisation : les outils, le processus, et les personnes dont le travail change. C’est un métier de terrain, exigeant et rarement décrit honnêtement, parce que sa partie la plus difficile n’est pas technique. Faire tenir ensemble des systèmes qui ne s’attendaient pas est un travail d’ingénierie ordinaire ; obtenir qu’une équipe qui n’a rien demandé change sa façon de travailler ne l’est pas. Le métier ressemble beaucoup à celui de forward deployed engineer et une seule chose les sépare vraiment, qui change tout le reste : l’identité de l’employeur. L’un est payé par l’éditeur du produit, l’autre par le client. Et la façon dont ce poste échoue est connue, prévisible, et pourtant répétée presque partout : la mission s’arrête au jour de la mise en service, alors que c’est le moment où le travail important commence.
Consultant en mise en œuvre IA, en bref
Métier émergent| En une phrase | Prend une décision déjà arrêtée et la met en fonctionnement dans l’organisation : outils, processus et personnes. |
|---|---|
| Jugé sur | Le fait que la chose tourne et soit utilisée à la fin de la mission. |
| Échoue quand | La mission s’arrête à la mise en service et l’organisation n’a jamais été rendue capable de la faire tourner seule. |
| Confondu avec | Le forward deployed engineer, qui fait un travail voisin en étant payé par l’éditeur. |
Un travail réel, dont le périmètre varie assez d’un employeur à l’autre pour que l’intitulé seul n’apprenne pas grand-chose. Aucun chiffre de rémunération : voir notre méthode.
Ce que recouvre la mise en œuvre
L’intégration. Authentification, habilitations, formats d’échange, systèmes amont indisponibles pendant la maintenance mensuelle, fenêtres de mise en production imposées. Rien de cela n’est intellectuellement difficile et tout cela prend du temps réel.
La reprise des données. La partie qui déborde le plus systématiquement, parce que les données ne ressemblent jamais à leur documentation, et que la découverte se fait toujours plus tard qu’elle ne le devrait.
Le processus. Ce qui change dans la façon de travailler, qui valide quoi, et ce qui se passe quand le système se trompe. Un déploiement qui laisse ces questions ouvertes produit un outil que personne n’ose utiliser.
La transmission. La documentation, le jeu d’évaluation, et une période où quelqu’un du client fait tourner le système pendant que le consultant répond à ses questions. C’est un livrable et non une réunion de clôture.
La différence avec le forward deployed engineer
Les deux métiers passent leurs journées chez un client, écrivent du code que personne ne relira, et expliquent la même technologie à des gens qui ne l’ont pas demandée. Ce qui les sépare est la position dans laquelle les place leur employeur.
Le forward deployed engineer porte l’intérêt à long terme de l’éditeur, ce qui inclut le droit et parfois le devoir de dire qu’une demande du client ne devrait pas être satisfaite, parce qu’elle produirait un système impossible à maintenir ou un précédent coûteux.
Le consultant est payé par le client et doit livrer ce qui a été commandé. Sa marge de refus est plus étroite, et sa protection tient à la qualité du cadrage initial plutôt qu’à une position dans la relation. C’est une raison de soigner particulièrement ce qui est écrit avant de commencer.
L’échec caractéristique, et comment l’éviter
La mission s’arrête au jour de la mise en service. Tout fonctionne, la facture est réglée, et l’organisation n’a jamais été rendue capable d’exploiter ce qu’elle possède désormais.
Six mois plus tard, un système amont change de format, le déploiement casse, et personne en interne ne sait où regarder. L’expérience laisse le souvenir d’une technologie fragile, alors qu’il s’agissait d’une transmission qui n’a pas eu lieu.
L’évitement est contractuel autant que technique. La mission comporte une phase de transmission, budgétée, avec des livrables nommés : la documentation d’exploitation, le jeu d’évaluation, et une période où une personne du client conduit pendant que le consultant accompagne. Une proposition qui ne contient pas cette phase propose un travail incomplet, même si tout le reste est excellent.
Pourquoi c’est une bonne porte d’entrée
Peu de métiers exposent à autant d’organisations différentes en aussi peu de temps. En deux ans, un consultant en mise en œuvre voit une dizaine d’environnements réels, avec leurs contraintes, leurs jeux d’acteurs et leurs façons particulières de résister au changement.
Cette exposition produit une compétence rare et entièrement transférable : ouvrir un système qu’on n’a pas écrit et y être utile en quelques jours, comprendre une organisation qu’on ne connaît pas et savoir à qui parler. Ces deux capacités servent partout ensuite, y compris chez les éditeurs, qui recrutent volontiers ces profils précisément pour cela.
