FDE vs consultant en mise en œuvre : la paire la plus proche
De tous les rapprochements possibles autour de ce métier, celui-ci est le plus serré. Les deux travaillent chez un client, écrivent du code d’intégration que personne ne relira, attendent les mêmes habilitations, et passent les mêmes semaines à convaincre des gens qui n’ont rien demandé. Pendant un mois entier, un observateur ne les distinguerait pas. La différence tient à qui les emploie, et elle se manifeste à deux moments précis. Le premier est l’arbitrage : quand une demande du client s’oppose à ce qui serait bon pour le produit, l’un peut dire non en invoquant l’intérêt de son employeur, l’autre doit livrer ce qui a été commandé. Le second est la fin : quand la mission s’achève, la question de ce qui reste dans l’organisation se pose différemment selon que le prestataire souhaite revenir vendre autre chose ou que l’éditeur souhaite que son produit continue d’être utilisé. Ces deux moments décident de la qualité de ce qui est livré bien plus que la compétence technique.
Le périmètre, plus large d’un côté
Le consultant est engagé sur un résultat dans l’organisation. Si le projet bute sur un système qui n’a rien à voir avec la technologie déployée, ce système entre dans son périmètre, parce que sans lui le résultat n’arrivera pas.
Le forward deployed engineer a un périmètre défini par le produit de son employeur. Ce qui est hors de ce périmètre reste hors de ce périmètre, ce qui le protège d’une dérive d’engagement et le prive parfois du moyen de résoudre le problème réel.
Cette différence explique une frustration que les deux camps expriment. Le consultant trouve l’ingénieur de l’éditeur rigide ; l’ingénieur trouve le consultant prêt à promettre n’importe quoi. Les deux ont raison depuis leur position.
Ce qui reste après la fin
Les deux métiers connaissent le même échec caractéristique : la mission s’arrête au jour de la mise en service et l’organisation n’a jamais été rendue capable d’exploiter ce qu’elle possède. Leurs incitations face à cet échec ne sont pourtant pas identiques.
L’éditeur a besoin que son produit continue d’être utilisé, parce que son renouvellement en dépend. Il a donc un intérêt économique direct à ce que la transmission réussisse, même si les équipes de déploiement sont parfois évaluées sur des livraisons plutôt que sur l’usage.
Le cabinet a besoin de revenir. Cela peut pousser dans le bon sens, une mission réussie ouvrant la suivante, et parfois dans le mauvais, quand une dépendance entretenue produit un flux de facturation. Les cabinets sérieux traitent cette tension explicitement ; les autres la laissent agir.
La conséquence pratique pour un client est de demander la même chose aux deux : que la transmission soit un livrable budgété, avec la documentation, le jeu d’évaluation et une période où une personne interne conduit.
Passer de l’un à l’autre
Le passage se fait dans les deux sens et il est courant, parce que la compétence centrale est identique. Ce qui change est ce qu’on apporte en arrivant.
Un consultant qui rejoint un éditeur apporte la connaissance des organisations réelles et des raisons pour lesquelles les déploiements échouent. C’est exactement ce qui manque d’ordinaire aux équipes produit, et cela explique pourquoi ces recrutements sont fréquents.
Un ingénieur de déploiement qui rejoint un cabinet apporte une profondeur technique que le conseil possède rarement, et la capacité de prototyper au lieu de supposer. Le point d’attention porte alors sur la rémunération, structurée autrement, et sur le rapport au temps facturable, qui est une contrainte nouvelle.
La relation avec l’équipe interne
Un dernier écart se manifeste tard et il compte pour ce qui reste. Le consultant travaille au milieu des équipes du client pendant des mois, parfois avec un bureau et un badge, et il construit des relations qui lui donnent accès à des informations qu’aucune réunion ne produit.
Le forward deployed engineer arrive comme fournisseur. Cela lui ouvre des portes en haut de l’organisation, parce qu’un dirigeant reçoit volontiers l’éditeur d’une technologie qu’il a achetée, et cela en ferme d’autres plus bas, où l’on se méfie davantage d’un vendeur que d’un prestataire installé.
Cet écart a une conséquence sur l’adoption, qui est le moment décisif des deux métiers. Le consultant obtient plus facilement qu’une personne lui dise ce qui ne va pas réellement, parce qu’elle le côtoie depuis trois mois. L’ingénieur de l’éditeur doit gagner cette confiance plus vite et avec moins d’occasions, ce qui rend sa présence sur place après la mise en service d’autant plus nécessaire.
Comment lire une annonce
Les intitulés étant employés indifféremment, deux questions suffisent à trancher. Qui paie votre salaire : l’entreprise qui a construit la technologie, ou celle qui la déploie chez un tiers. Et que se passe-t-il quand le client demande quelque chose que le produit ne devrait pas faire.
La seconde question est la plus instructive en entretien, parce que la réponse décrit la culture réelle de l’équipe bien plus que la fiche de poste. Une équipe qui répond que cela n’arrive jamais n’a pas encore déployé beaucoup.
