FDE, consultant, ESN ou régie : quelle différence, et quand choisir quoi

Un même besoin, quatre façons de le couvrir

Le point de départ se ressemble d'une entreprise à l'autre. Une équipe recopie des données d'un fichier vers un autre toute la journée. Un service achats attend une information qui existe déjà quelque part dans le système. Une direction financière refait le même reporting à la main chaque mois. Le dirigeant voit le problème. Ce qu'il ne voit pas, c'est à qui le confier.

Quatre réponses existent sur le marché : le cabinet de conseil, la société de services au forfait, la régie, et le forward deployed engineer. Elles emploient souvent les mêmes mots dans les propositions commerciales : accompagnement, expertise, delivery, transformation. Elles ne vendent pourtant pas la même chose, et elles ne répondent pas à la même question.

Aucun de ces modèles n'est meilleur que les autres dans l'absolu. Chacun a un terrain où il est le bon choix, et un terrain où il coûte cher pour rien. L'erreur habituelle n'est pas de choisir un mauvais prestataire, c'est de le choisir pour une question qui n'est pas la sienne.

Pour chaque modèle, nous regardons cinq points : ce que vous achetez vraiment, qui porte le risque si le résultat n'arrive pas, qui pilote au quotidien, ce qui reste dans l'entreprise à la fin, et le cas typique où c'est le bon choix.

Le cabinet de conseil

Ce que vous achetez. Un regard extérieur et une décision éclairée. Le cabinet cadre le problème, compare les options, construit une trajectoire et accompagne le changement dans les équipes. Il produit des recommandations, une feuille de route, des comités de pilotage, parfois un cahier des charges. Il ne produit pas de logiciel.

Qui porte le risque. Vous. Le cabinet s'engage sur la qualité de l'analyse et sur la tenue de son propre calendrier. Il ne s'engage pas sur le fait que la solution recommandée fonctionnera une fois construite, puisqu'il ne la construit pas. Si la recommandation est juste sur le papier mais inapplicable dans votre système d'information, l'écart se découvre plus tard, chez quelqu'un d'autre.

Qui pilote au quotidien. Un directeur de mission, avec une équipe qui tourne selon les phases. Vous pilotez par les livrables et par les comités, pas par le travail de la journée.

Ce qui reste à la fin. Des documents, une vision partagée entre les directions, et souvent quelque chose de plus utile encore : un arbitrage assumé. Quand un sujet bloque parce que deux directions ne sont pas d'accord, un tiers crédible qui tranche vaut plus que n'importe quel outil.

Le cas typique. Vous ne savez pas encore quoi faire. Le problème traverse plusieurs directions, il touche l'organisation autant que la technique, et l'enjeu porte sur plusieurs années. Le cabinet est aussi le bon choix quand le vrai chantier n'est pas l'outil mais l'adoption : faire changer des habitudes installées relève de la conduite du changement, pas du code.

La société de services au forfait

Ce que vous achetez. Un périmètre écrit, livré pour un prix convenu. Vous décrivez ce que vous voulez, le prestataire spécifie, chiffre, développe, recette et livre. Le contrat porte sur un résultat délimité : ces écrans, ces fonctions, ces interfaces, cette reprise de données.

Qui porte le risque. Le prestataire, mais seulement à l'intérieur du périmètre écrit. C'est la nuance qui décide du succès ou de l'échec. Tout ce qui est dans le document est à sa charge. Tout ce qui n'y est pas devient un avenant. Or, sur un sujet métier mal connu au départ, l'essentiel de ce qui compte se découvre pendant le projet, donc en dehors du document.

Qui pilote au quotidien. Un chef de projet côté prestataire, un chef de projet côté client. Vous pilotez par la conformité au périmètre : ce qui a été livré, ce qui reste, ce qui dérive. C'est un pilotage de contrôle, pas un pilotage d'exploration.

Ce qui reste à la fin. Une application, une documentation, un contrat de maintenance. La connaissance du métier, elle, reste largement chez le prestataire, dans la tête de ceux qui ont fait les choix d'implémentation. C'est la raison pour laquelle la réversibilité se prépare au début et jamais à la fin.

Le cas typique. Le besoin est stable, connu, déjà vécu ailleurs. Vous savez écrire ce que vous voulez sans vous tromper. Le forfait donne alors une visibilité que rien d'autre ne donne : un budget ferme et une date. C'est le bon modèle pour un remplacement de système dont les règles sont documentées, une refonte à iso périmètre, une intégration entre deux outils du marché. Avant de lancer un forfait, tranchez une question pour de bon : construire ou acheter ? Nous l'avons traitée dans sur-mesure ou logiciel du marché.

La régie, ou prestation de personnel

Ce que vous achetez. Une compétence disponible, dans votre équipe, sur le temps que vous décidez. Un développeur, une data engineer, une administratrice système vient travailler chez vous, sur vos outils, dans vos rituels. Vous achetez de la capacité de travail, pas un résultat.

Qui porte le risque. Vous, entièrement. Le prestataire s'engage sur la compétence et sur la présence. Si la personne travaille sur le mauvais sujet, ou si personne ne lui dit quoi faire, la facture tombe quand même. La régie transfère une charge de recrutement, elle ne transfère aucun risque de résultat.

Qui pilote au quotidien. Vous, et c'est la condition d'entrée. Il faut quelqu'un chez vous capable de découper le travail, d'arbitrer les priorités, de relire et de valider. Sans ce rôle tenu par un interne, une régie dérive vite, sans que personne le voie tout de suite.

Ce qui reste à la fin. Le code, et ce que votre équipe a appris à côté de la personne. C'est réel : sur une techno nouvelle pour vous, un bon profil en régie fait monter une équipe interne plus vite qu'une formation. Le sujet rejoint celui de la montée en maturité des équipes.

Le cas typique. Vous savez quoi faire, vous savez comment le faire, il vous manque des bras ou une compétence précise. Un pic d'activité, un départ à remplacer le temps d'un recrutement, une expertise pointue sur une brique. La régie est lisible et sous-estimée : quand le pilotage interne existe vraiment, c'est souvent la réponse la plus simple.

Le forward deployed engineer

Ce que vous achetez. Un ingénieur qui vient voir le travail réel avant d'écrire la première ligne. Il s'assoit à côté des personnes concernées, regarde comment elles font, où elles perdent du temps, ce qu'elles contournent. Puis il construit, sur vos données, et il revient vérifier que l'outil est utilisé. Ce qui est acheté n'est pas un cahier des charges exécuté : c'est un problème qui disparaît du quotidien des équipes. C'est le modèle que nous pratiquons chez Kabaun Studio, décrit sur la page FDE as a service.

Qui porte le risque. Le prestataire, sur l'usage et pas seulement sur la livraison. La différence se voit à la question posée en fin de mission. Au forfait, on demande : est-ce conforme à ce qui était écrit ? En mode forward deployed, on demande : les équipes ont-elles gagné du temps, et continuent-elles de s'en servir quand plus personne ne regarde ?

Qui pilote au quotidien. L'ingénieur pilote sa propre construction, avec les utilisateurs, et rend compte au responsable métier. Le comité n'est pas supprimé, il sert à arbitrer les priorités plutôt qu'à valider des écrans. Cela suppose un sponsor côté client, capable de dire quelle irritation traiter en premier.

Ce qui reste à la fin. Un outil en service, le code et les accès chez vous, et une connaissance du métier écrite noir sur blanc parce qu'elle a été observée. C'est aussi ce qui permet à un premier essai de survivre au passage en production, sujet détaillé dans les prérequis d'un POC métier.

Le cas typique. Le besoin est réel mais mal formulé. Les utilisateurs décrivent leur travail en termes d'exceptions, de cas particuliers, de fichiers à eux. Personne ne sait écrire le cahier des charges parce que la connaissance est dans les mains, pas dans les documents. Le forward deployed engineer est fait pour cette situation précise : quand la spécification est justement ce qu'il faut produire, et pas ce qu'il faut recevoir.

Les questions à poser avant de choisir

Le modèle se déduit moins d'une préférence que de quelques réponses honnêtes. Prenez ces questions dans l'ordre, et notez celles sur lesquelles vous hésitez.

• Sommes-nous capables d'écrire aujourd'hui ce que nous voulons, sans nous tromper ?
• La question ouverte est-elle stratégique, organisationnelle ou technique ?
• Qui, chez nous, arbitrera les priorités chaque semaine, nommément ?
• Sur quoi voulons-nous que le prestataire soit jugé : un livrable, une date, ou un usage constaté ?
• Que devons-nous absolument garder à la fin : le code, les données, la compétence ?
• Les utilisateurs finaux sont-ils accessibles, et pouvons-nous libérer leur temps pour les observer ?
• Sommes-nous tenus par une procédure d'achat qui impose un périmètre figé et une mise en concurrence ?
• Si le projet s'arrête demain, que reste-t-il d'utilisable en l'état ?

Une règle simple s'en dégage. Si vous hésitez surtout sur la première question, aucun forfait ne vous sauvera : il faut d'abord produire la spécification, par un cadrage ou par une présence terrain. Si vous hésitez sur la troisième, écartez la régie tant que le pilote n'est pas nommé.

Les modèles mixtes, qui marchent souvent le mieux

Dans la pratique, les entreprises qui s'en sortent le mieux n'achètent pas un modèle pur. Elles enchaînent deux modèles, en sachant pourquoi elles changent.

Cadrage par un cabinet, puis construction par un forward deployed engineer. Le cabinet tranche ce qui doit l'être au niveau de la direction : quel processus on garde, lequel on abandonne, qui devient responsable de quoi. L'ingénieur prend ensuite le terrain et construit ce qui reste à construire. La condition de réussite est que le cadrage s'arrête avant les détails d'implémentation. Un cadrage qui va jusqu'aux écrans fige des choix que personne n'a encore confrontés aux données réelles.

Forward deployed pour démarrer, reprise par l'équipe interne. C'est le montage le plus courant, et il se prépare dès la première semaine. L'ingénieur construit en expliquant, dans les technologies que votre équipe sait tenir, avec les accès au dépôt et à l'hébergement chez vous. La reprise n'est pas un transfert de fin de mission avec une réunion et un document. C'est un travail côte à côte qui a commencé bien avant.

Forfait pour la brique connue, forward deployed pour la partie floue. Un projet contient souvent une part parfaitement spécifiable, par exemple une reprise de données ou une interface documentée, et une part incertaine, le nouveau geste métier. Les séparer en deux contrats évite de payer la souplesse sur ce qui n'en a pas besoin, et d'imposer un périmètre figé à ce qui doit encore bouger.

Régie après la mise en service. Une fois l'outil en place et la connaissance transmise, la maintenance évolutive n'a plus besoin d'observation terrain. Un profil en régie, piloté par votre responsable, suffit largement.

Quand un forward deployed engineer n'est pas le bon choix

Un modèle honnête se reconnaît à sa capacité de dire quand il ne sert à rien. Quatre situations doivent vous en détourner.

Le besoin est parfaitement spécifié et stable. Si le document existe, qu'il a été relu par les gens qui feront le travail, et que rien ne bougera pendant la construction, vous n'avez pas besoin de quelqu'un qui vienne observer. Vous avez besoin d'une équipe qui exécute bien et d'un engagement de date. C'est exactement ce que le forfait fait mieux que tout le reste.

Un logiciel du marché couvre le besoin. Beaucoup de problèmes racontés comme uniques sont des problèmes très ordinaires, déjà résolus par un produit dont c'est le métier. Payer une construction sur-mesure pour refaire une gestion commerciale standard est un mauvais calcul, même bien menée. La même prudence vaut pour les automatisations simples : quand un outil de flux suffit, il suffit, et nous l'écrivons dans le comparatif entre outils de flux et sur-mesure.

Vous êtes tenu par une mise en concurrence sur cahier des charges figé. Certaines organisations, publiques ou non, doivent acheter sur un périmètre écrit, comparé ligne à ligne entre plusieurs offres. Le mode forward deployed s'y prête mal, parce que sa valeur tient justement à ce qui n'est pas encore écrit. Dans ce cadre, la présence terrain a sa place en amont, pour produire le cahier des charges, puis le marché se passe normalement.

Il vous manque simplement des bras sur une techno précise. Si vous savez quoi faire, si le pilotage interne existe et si le sujet est clair, faire venir un ingénieur pour observer le métier est un détour inutile. La régie répond mieux, plus simplement.

Il existe un cinquième cas, plus délicat à dire : quand personne, chez vous, n'a le temps ni le mandat de travailler avec l'ingénieur. Le modèle forward deployed suppose un accès aux équipes et un sponsor qui tranche. Sans cela, la mission produit un outil correct que personne n'utilise, et le problème d'origine reste entier.

Choisir, puis vérifier

Le bon réflexe n'est pas de comparer des prestataires, mais de qualifier votre propre situation : ce que vous savez écrire, ce que vous savez piloter, et ce que vous voulez garder. Le modèle se déduit ensuite presque tout seul, et il peut changer en cours de route sans que ce soit un échec. Pour comprendre en détail le quatrième modèle et ce qui le distingue des trois autres, commencez par notre page de référence sur le forward deployed engineer. Si vous voulez poser votre cas à voix haute avant de décider quoi que ce soit, le diagnostic est fait pour ça : on regarde le problème, pas la solution.

Questions fréquentes

Un cabinet de conseil peut-il aussi développer la solution qu'il recommande ?

Certains cabinets ont une entité de réalisation, d'autres travaillent avec des partenaires. La question à poser est celle de l'engagement : le même contrat couvre-t-il la recommandation et la mise en service ? Quand les deux sont séparés, prévoyez qui reprend la connaissance produite pendant le cadrage, sinon elle se perd au passage de relais.

Comment savoir si notre besoin est assez spécifié pour un forfait ?

Un test simple : demandez à deux personnes du métier de décrire indépendamment le même processus, exceptions comprises. Si les deux récits divergent sur des points importants, le besoin n'est pas encore spécifié, quel que soit l'état du document. Dans ce cas, produisez la spécification avant d'acheter un périmètre fermé.

Un forward deployed engineer travaille-t-il sur place ou à distance ?

Les deux, selon le sujet. Ce qui compte n'est pas le lieu mais l'accès : voir les utilisateurs travailler, ouvrir les vrais fichiers, assister aux moments où le processus casse. Une mission entièrement à distance reste possible si ces accès sont organisés sérieusement, sinon elle retombe vite dans un mode projet classique.

Peut-on changer de modèle en cours de route sans tout recommencer ?

Oui, à condition que le code, les données et les accès soient chez vous dès le départ. C'est la seule précaution qui rend un changement indolore. Passer d'un forward deployed engineer à une équipe interne, ou d'une régie à un forfait, est fréquent et sain quand le sujet a changé de nature.

Quel interlocuteur interne faut-il prévoir dans chaque modèle ?

Pour un cabinet, un sponsor de direction capable de trancher entre services. Pour un forfait, un chef de projet qui tient le périmètre et la recette. Pour une régie, un responsable technique qui découpe et valide le travail chaque semaine. Pour un forward deployed engineer, un responsable métier qui donne accès aux équipes et arbitre les priorités.