5 erreurs qui ont tué un mandat en 10 jours

Une boîte américaine me contacte pour reprendre un projet. On négocie les termes du contrat, mon rôle est clair sur le papier, uniquement du développement. Ils ont déjà des équipes pour l'infra et le reste. Le projet est terminé à 90%, l'objectif est de le mettre en ligne le plus vite possible.

Moi, je me chauffe. Travailler avec l'oncle Sam, je trouve ça cool. Une bonne aventure à vivre, même à distance. Et qui sait, sur le long terme, j'irais bien leur rendre visite en vacances. California!

Le mandat a duré 10 jours. On a arrêté d'un commun accord.

Je pourrais raconter cette histoire en me donnant le beau rôle. Le client par-ci, le contexte par-là. Ce serait facile, et surtout inutile. Parce que la vraie question, c'est pourquoi moi, avec mon expérience, je n'ai pas vu venir ce qui allait se passer. Voici les 5 erreurs que j'ai faites, et ce que je ferai différemment la prochaine fois.

Ce métier a un nom : forward deployed engineer

Je n'avais pas le titre. Personne ne l'a employé dans le contrat. Mais la forme du travail était exactement celle-là.

Un forward deployed engineer, abrégé FDE, est un ingénieur embarqué dans l'équipe du client, qui écrit du code de production dans l'infrastructure du client, sur ses données, avec ses contraintes. Le terme ne se traduit pas, comme la plupart du vocabulaire technique, alors je le garde tel quel. Le modèle a été inventé chez Palantir en 2006, et les entreprises d'IA l'ont adopté massivement depuis, parce qu'un modèle qui marche en démo et un modèle qui marche dans une entreprise sont deux problèmes différents. OpenAI, Anthropic et Palantir recrutent aujourd'hui sous ce titre exact.

Presque tout ce qui s'écrit sur ce rôle vient d'un seul côté de la table. Des guides de carrière pour nouveaux embauchés, de la préparation d'entretien, des playbooks écrits par le vendeur pour ses propres salariés. Utile, et incomplet.

Cet article est l'autre côté. Un indépendant, embarqué, sur un mandat mort en dix jours.

Et voilà ce que je veux en tirer. Les cinq erreurs qui suivent ne sont pas des erreurs de débutant. Ce sont les risques structurels du modèle embarqué. Quand tu travailles dans l'infrastructure de quelqu'un d'autre, sur son code, avec ses accès, la frontière de ton mandat n'existe que si quelqu'un l'écrit. Le forward deployed engineering est le rôle où cette frontière est la plus floue par construction, et les modes d'échec sont toujours les cinq mêmes.

Erreur 1. J'ai signé sans clarifier les rôles et les responsabilités

Sur le papier, tout était simple. Moi le développement, eux l'infra et le reste.

En pratique, dès les premiers jours, j'avais besoin d'accès aux serveurs, au DNS, aux services tiers. Personne n'avait défini qui fournit quoi, ni quand, ni comment. Alors j'ai fait ce que font beaucoup d'indépendants, j'ai enfilé la casquette manquante. La casquette devops s'est ajoutée au mandat, sans accès complets, sans périmètre, sans que le cadrage soit rediscuté.

C'est dans mes compétences, donc j'ai dit oui. J'aurais dû dire non. Pas parce que je ne savais pas le faire, mais parce qu'accepter une responsabilité sans les moyens qui vont avec, ça dessert le projet. Chaque casquette ajoutée en cours de route sans renégocier le cadre, c'est une zone grise de plus. Et les zones grises, c'est là que les projets meurent.

Ce que je retiens. La définition des rôles n'est pas une formalité de contrat. C'est le livrable numéro zéro. Si le périmètre bouge, le cadrage doit être rediscuté le jour même, pas subi en silence.

Erreur 2. J'ai accepté de travailler sans suivi de projet

Au kickoff, le message était direct. Pas de suivi, il faut que ça aille vite. Si j'ai besoin d'une info, je demande. Le seul output attendu, c'est la mise en ligne, peu importe les bugs, on corrigera après.

J'ai entendu "moins d'admin, plus de code" et j'ai trouvé ça presque confortable. Grosse erreur.

Le suivi de projet, j'essaie toujours de le mettre en place, et en pratique ça ne marche pas toujours bien, je le sais. Mais au lancement d'une collaboration, il est irremplaçable. Pas pour faire joli. Pour construire la confiance en montrant l'avancée, pour documenter le travail, pour créer un langage commun entre ce que je fais et ce que le client perçoit.

Sans suivi, quand le rythme a semblé lent côté client, je n'avais rien à montrer. Pas de trace, pas de jalons, pas de réalité partagée. Juste ma parole contre une impression.

Ce que je retiens. Le suivi n'est pas négociable en début de collaboration. C'est précisément quand le client veut aller vite qu'il en a le plus besoin, parce que c'est la seule chose qui rend la vitesse visible.

Erreur 3. Je n'ai pas verrouillé l'implication du client

Porter un projet et en déléguer la réalisation, ça ne veut pas dire s'en détacher à 100%.

Le projet avait été vibe codé. Ce n'est pas le problème, je reprends des projets vibe codés, c'est même devenu une partie de mon métier. Le problème, c'est la quantité. Une masse énorme de code, de documentation et de versions. Un historique de quelques mois de prompts qui, il y a encore trois ans, aurait représenté le travail d'une équipe entière sur plusieurs trimestres.

Dans une masse pareille, des décisions remontent tous les jours. Quelle version fait foi. Quelle fonctionnalité est abandonnée. Quel comportement est un bug et lequel est voulu. Ces décisions, seul le client peut les prendre. Et si le client n'est pas disponible, ou n'a plus la vision d'ensemble sur son propre projet, tout s'arrête.

Je n'avais rien prévu pour ça. Pas de rendez-vous de décision, pas de délai de réponse convenu, pas de personne identifiée comme arbitre.

Ce que je retiens. Avant de commencer, je verrouille la disponibilité du client. Qui décide, sous quel délai, sur quel canal. Déléguer la réalisation exige plus d'implication du client au démarrage, pas moins.

Erreur 4. J'ai laissé l'expérience du client remplacer l'audit

"Le projet est terminé à 90%." Dans ce métier, tout le monde sait ce que vaut cette phrase. Moi aussi. Personne ne croit un "terminé à 90%", c'est presque un running gag entre développeurs.

Alors pourquoi je n'ai pas creusé ? Parce que le chiffre venait d'un client technique, avec de longues années d'IT et de gestion de projet derrière lui. Je me suis dit qu'il savait ce que "terminé" veut dire, que son estimation était informée, que le cadrage tenait la route. Ce n'est pas le chiffre que j'ai cru, c'est l'expérience de celui qui l'annonçait.

La réalité sous la surface, c'était du code mort, de la documentation périmée parce que le cadrage initial n'avait jamais été consolidé, des fonctionnalités qui marchaient uniquement sur le chemin idéal. Et des cas limites impossibles à reproduire, ceux qui transforment les 10% restants en 90% du travail.

Je n'ai pas fait d'audit avant de m'engager. Pas d'état des lieux, pas de définition partagée de ce que "terminé" veut dire. La crédibilité du client m'a servi de garantie, et j'ai laissé cette garantie remplacer ma propre vérification.

Ce que je retiens. L'expérience du client ne remplace pas l'audit. Même technique, même senior. Surtout technique et senior, en fait, parce que plus le client est crédible, plus ses estimations passent sans contrôle. Un ou deux jours facturés pour établir l'état réel du projet, c'est ce qui protège les deux parties. La confiance ne dispense pas de vérifier.

Erreur 5. Je n'ai pas fait la pédagogie de mon propre travail

Cette erreur, c'est le miroir de la précédente. J'ai cru son expertise sans la vérifier. Et j'ai supposé que la mienne se voyait sans l'expliquer.

Le terrain était connu dès le départ. Le projet vivait sur Vercel avec un Supabase serverless, et il devait passer en self-hosted, en Suisse, avec une vraie architecture sur une infra souveraine. Je le savais en signant. Ce n'est pas ça le problème.

Le problème, c'est l'écart entre les deux mondes. Déployer sur Vercel, c'est cool, ça marche, ça va vite. Surtout quand c'est Claude qui le fait à ta place. La sécurité, les backups, on verra plus tard. Le self-hosted, c'est un autre sport. Configurer un DNS, activer un SSH, récupérer les bonnes variables d'environnement, brancher chaque service proprement. Le devops, c'est minutieux. Une mauvaise indication à l'IA, et rien ne fonctionne.

Ce décalage, je le connaissais. Mais expliquer pourquoi une infra propre demande deux ou quatre jours à quelqu'un qui vient de voir 95% du travail se faire en un, ça ressemblait à me justifier. Alors je ne l'ai pas fait. Ni chiffré, ni planifié, ni annoncé. J'ai laissé mon travail devenir invisible, et le malentendu s'est installé exactement là.

Ce que je retiens. La pédagogie fait partie du mandat, même face à un expert, parce que son expertise n'est pas la mienne. Rendre visible le travail invisible, chiffré, planifié, expliqué à voix haute, ce n'est pas se justifier. C'est la seule chose qui empêche un écart de perception de devenir une rupture.

Ce que ce mandat m'a appris

Au jour 10, on s'est parlé honnêtement et on a arrêté d'un commun accord. Pas de clash, pas de rancune. Juste le constat que les conditions ne permettaient pas de faire du bon travail.

Je pourrais invoquer des circonstances atténuantes, et il y en a. Ça ne changerait rien au fond. Anticiper ces cinq points, c'était mon travail. C'est même exactement ça, être indépendant. L'expertise ne s'arrête pas au code, elle inclut le cadre qui protège le projet, et le courage de dire non quand ce cadre n'existe pas.

Ce mandat m'a permis de completer une checklist que j'applique maintenant sur chaque reprise de projet, et que je donnerais telle quelle à n'importe qui accepte une mission de forward deployed engineer. Un audit avant de m'engager. Les accès dès le jour un. Un suivi non négociable au démarrage. Un décideur identifié et disponible. Et la pédagogie du travail invisible, chiffrée et annoncée dès le départ, même quand le client est un expert.

Remarque qu'aucun point de cette liste n'est technique. C'est ce que la littérature sur le FDE sous-estime. Être embarqué n'est pas d'abord un problème de code, c'est un problème de frontière. L'ingénierie n'a jamais été ce qui mettait ce mandat en danger.

L'aventure américaine attendra. La prochaine fois, j'irai avec un meilleur contrat. Et peut-être quand même en vacances.

Si tu portes un projet vibe codé qui doit passer du prototype au produit, je propose un audit gratuit. Je regarde ton produit, je te dis honnêtement où il en est, et ce que les derniers "10%" cachent vraiment. Sans engagement, sans jargon. C'est exactement le but de mon offre Du prototype au produit.