FDE vs consultant IA : qui paie, et ce que cela change
Les deux métiers passent leurs journées chez des clients, expliquent la même technologie à des gens qui ne l’ont pas demandée, et se heurtent aux mêmes délais d’accès aux données. Ce qui les sépare tient en une question : qui paie. Le forward deployed engineer est payé par l’éditeur du produit ; le consultant, par le client. Cette différence paraît administrative et elle décide de tout ce qui compte. Elle décide de ce qu’il est possible de refuser : un ingénieur qui porte l’intérêt à long terme de son employeur peut dire qu’une demande ne devrait pas être satisfaite, parce qu’elle produirait un système impossible à maintenir ou un précédent coûteux, et c’est une partie légitime de son travail. Le consultant doit livrer ce qui a été commandé, et sa protection tient à la qualité de ce qui a été écrit avant de commencer. Elle décide aussi de ce que chacun connaît le mieux : le produit pour l’un, le secteur du client pour l’autre.
Le droit de refuser, et ce qu’il protège
Une demande client qui produirait un système fragile arrive dans tous les déploiements. Elle est raisonnable du point de vue de celui qui la formule, et elle coûtera cher dans dix-huit mois à quelqu’un qui n’est pas dans la pièce.
Le forward deployed engineer peut la refuser en invoquant l’intérêt du produit, et ce refus est attendu de lui. Il protège le client autant que l’éditeur, même si le client ne le voit pas ainsi sur le moment.
Le consultant n’a pas cette position. Il peut conseiller, argumenter, écrire une réserve, et au bout du compte le client décide. Sa seule protection réelle est le cadrage : ce qui a été écrit avant de commencer sur le périmètre, sur ce qui sera transmis et sur ce qui ne sera pas fait.
Ce que chacun connaît mieux
Le forward deployed engineer connaît le produit de l’intérieur. Il sait ce qui arrive au trimestre suivant, quelles limites sont structurelles et lesquelles seront levées, et à qui s’adresser dans l’équipe cœur quand quelque chose ne fonctionne pas comme annoncé.
Cet avantage est considérable sur un déploiement du produit en question et nul sur tout le reste. Il ne se transfère pas d’un employeur à l’autre, ce qui est une chose à savoir avant de faire de sa maîtrise d’un produit son principal atout professionnel.
Le consultant connaît mieux le secteur, et cette connaissance se transfère intégralement. Quelqu’un qui a mené huit projets dans la banque sait où se trouvent les données, qui autorise quoi et combien de temps prend une revue, et cela vaut chez n’importe quel client suivant.
Le même obstacle, traité différemment
Les deux métiers rencontrent le même obstacle principal : l’accès aux données et l’adoption. Ils ne disposent pas des mêmes leviers pour le traiter.
Le consultant est à l’intérieur du dispositif du client, souvent pour plusieurs mois, parfois avec un bureau. Il peut aller voir des gens, s’asseoir dans des réunions auxquelles il n’était pas invité, et construire une relation avec l’équipe qui détient les accès.
Le forward deployed engineer arrive comme fournisseur, ce qui ouvre certaines portes en haut de l’organisation et en ferme d’autres plus bas. En revanche, il peut faire intervenir son employeur : une escalade commerciale débloque parfois en deux jours ce qu’une relation aurait mis deux mois à obtenir.
Trois métiers sous un seul intitulé
Une difficulté propre à ce comparatif mérite d’être nommée : le mot consultant désigne trois métiers différents selon le cabinet, et la comparaison change selon celui dont on parle.
Le conseil qui recommande et repart est le plus éloigné du déploiement : son livrable est un document, sa valeur tient au raisonnement, et il ne rencontre jamais les problèmes d’intégration qui occupent la moitié d’une mission de terrain.
Le conseil qui met en œuvre est le plus proche, au point que seule l’identité de l’employeur les sépare. Et le conseil qui travaille sur le mode de fonctionnement de l’organisation est encore autre chose : il ne construit rien et bute sur des décisions de pouvoir plutôt que sur des systèmes.
La question à poser reste donc la même dans tous les cas, et elle vaut avant un entretien comme avant une mission : qui construit. La réponse range l’annonce en quelques secondes.
Choisir entre les deux
Le critère le plus fiable n’est pas la rémunération, qui dépend davantage de la catégorie d’employeur que de l’intitulé, ni le niveau technique, qui est comparable.
C’est le rapport au produit. Si vous aimez connaître une chose en profondeur, savoir pourquoi elle a été conçue ainsi et influencer ce qu’elle deviendra, le déploiement chez un éditeur vous conviendra. Si vous préférez la variété des contextes et l’indépendance vis-à-vis d’un produit particulier, le conseil vous conviendra mieux.
Le second critère est le rythme. Le conseil enchaîne des missions relativement courtes chez des clients différents ; le déploiement s’installe plus longtemps chez les mêmes comptes. Les deux rythmes pèsent différemment sur une vie, et c’est la raison de départ la plus fréquente dans les deux métiers, loin devant l’ennui ou la rémunération.
