FDE ou consultant : quelles différences concrètes

La différence tient au livrable. Un consultant produit une analyse et une recommandation, dont la valeur existe même si personne ne les applique tout de suite. Un FDE produit un système qui tourne, et son travail ne vaut rien tant que ce système ne tourne pas. Tout le reste, le rythme, le rattachement, la façon de mesurer, découle de cet écart.

Ce que produit chacun

Le consultant travaille sur une question : faut-il faire ceci, dans quel ordre, à quel coût, avec quels risques. Il rassemble ce qui est épars, met en regard des options, et rend un jugement argumenté. Sa réussite se mesure à la qualité de la décision qu’il permet.

Le FDE travaille sur un objet. Il construit, branche, corrige, jusqu’à ce qu’une personne dont ce n’est pas le métier utilise le résultat sans y penser. Sa réussite se mesure à l’usage.

Les deux métiers demandent de comprendre l’organisation. Ils divergent sur ce qu’ils en font. Le consultant transforme cette compréhension en recommandation ; le FDE la transforme en configuration, en règles et en code.

Le livrable et sa durée de vie

Un rapport vieillit lentement et proprement. Six mois plus tard, il est daté mais lisible, et l’on sait sur quoi il reposait.

Un système vieillit vite et salement. Il continue de fonctionner alors que ses hypothèses ne tiennent plus, ce qui est plus dangereux qu’une panne franche. C’est pourquoi la question de la reprise se pose dès le premier jour d’une mission de terrain, alors qu’elle ne se pose presque jamais pour une mission de conseil.

Cet écart explique un malentendu fréquent sur les coûts. Le conseil se compare facilement parce que le livrable est borné. Le déploiement se compare mal, parce qu’une part du travail sert à découvrir ce qu’il fallait faire. Comparer les deux sur le seul montant revient à comparer un devis fermé et un devis ouvert sans le dire.

Faut-il choisir entre les deux ?

Dans la plupart des projets, non : ils interviennent à des moments différents.

Le conseil est le bon choix quand la question ouverte est « quoi ». Une organisation qui hésite entre trois chantiers, qui ne sait pas lequel produira le plus d’effet, ou qui doit convaincre un comité, a besoin d’une analyse avant d’avoir besoin d’un ingénieur. Envoyer quelqu’un construire à ce stade produit un objet techniquement correct au service d’un objectif que personne n’a arbitré. C’est le travail que couvre le conseil en IA, et le sauter coûte plus cher que de le faire.

Le déploiement est le bon choix quand la question ouverte est « comment ». La direction est claire, le premier essai a montré que la difficulté n’était pas dans le modèle mais dans les données et les habitudes, et il faut quelqu’un sur place. C’est le moment où le rôle de Forward Deployed Engineer prend son sens.

L’erreur coûteuse n’est pas de choisir l’un plutôt que l’autre. C’est de demander à l’un le livrable de l’autre : attendre d’un rapport qu’il fasse fonctionner quelque chose, ou d’un ingénieur qu’il arbitre une stratégie.

Trois différences pratiques

Le rattachement. Le consultant reste extérieur, et cette extériorité fait partie de son utilité : elle lui permet de dire ce que les équipes ne peuvent pas dire. Le FDE s’intègre, et cette intégration fait partie de la sienne : elle lui donne accès à ce que personne n’écrit dans un cahier des charges. Les deux positions sont incompatibles dans la même personne au même moment.

Le rapport à l’imprévu. Une mission de conseil absorbe mal les surprises, parce que le périmètre a été négocié à partir d’une question. Une mission de terrain les absorbe par construction, parce que la découverte fait partie du travail. Une organisation qui veut un budget ferme et un périmètre stable demande en réalité du conseil, quel que soit le nom qu’elle donne à la mission.

La sortie. Le consultant part quand le rapport est rendu, et son départ ne casse rien. Le FDE part quand quelqu’un d’autre sait faire, ce qui est une condition beaucoup plus difficile à remplir. Une mission de terrain sans plan de transmission laisse un système que l’organisation ne saura pas faire évoluer, et c’est le mode d’échec le plus fréquent.

Comment trancher dans un cas réel

Une question suffit le plus souvent : si le travail rendu était parfait mais que personne ne l’utilisait pendant six mois, aurait-il encore de la valeur ?

Si oui, c’est du conseil, et il faut le traiter comme tel. Si non, c’est du déploiement, et il faut accepter ce qui va avec : un périmètre mouvant, une présence longue, et une mesure de succès qui porte sur l’usage plutôt que sur la livraison. Cette même logique s’applique au cadrage plus large d’une transformation IA avec AI Makers, où les deux modes se succèdent plutôt qu’ils ne s’opposent.