Projet confié à une ESN : comment éviter les malentendus qui font déraper le delivery

Un projet confié à une ESN dérape rarement d'un coup.

Au départ, tout semble clair. Le budget est cadré. Le planning existe. Le périmètre a été discuté. Les premiers ateliers se passent bien.

Puis, quelques mois plus tard, la relation se tend.

Le client trouve que le produit ne correspond pas à ce qu'il avait en tête. L'ESN estime avoir livré ce qui était demandé. Les priorités changent, mais le budget ne bouge pas. Les comités projet parlent planning, charge restante et tickets fermés, mais peu des risques de fond.

Chacun cherche alors l'origine du problème.

Le client se demande si l'ESN est vraiment au niveau.
L'ESN se demande si le client sait ce qu'il veut.
Les équipes se protègent.
La confiance baisse.

Pourtant, le problème vient rarement d'un seul côté.

Une ESN peut être sérieuse, compétente et impliquée, tout en produisant un résultat décevant. Un client peut être de bonne foi, disponible et engagé, tout en créant les conditions d'un delivery difficile.

Le vrai sujet est souvent ailleurs : il manque quelqu'un pour faire le lien entre la vision métier, les contraintes techniques, le budget, le planning et les décisions à prendre.

C'est précisément là qu'un référent technique côté client devient utile.

Pas pour surveiller l'ESN.
Pas pour chercher un coupable.
Pas pour ajouter une couche de contrôle.

Mais pour remettre de la clarté entre les deux parties.

Externaliser le développement ne veut pas dire externaliser le risque

Beaucoup de projets externalisés partent d'une idée simple : le client doit construire ou faire évoluer un produit, mais il ne dispose pas de l'équipe technique nécessaire en interne.

Il confie donc le développement à une ESN.

C'est souvent pertinent. Une ESN peut apporter une équipe déjà constituée, des compétences variées, une capacité de production rapide, une méthode projet et un cadre contractuel.

Mais une confusion apparaît vite.

Le client pense parfois :

J'ai externalisé le développement, donc j'ai externalisé le risque.

En réalité, il a surtout externalisé l'exécution. Parfois une partie du conseil. Parfois une partie de la conception. Mais il reste responsable d'éléments que personne ne peut porter à sa place : vision produit, priorités métier, budget, arbitrages et niveau d'exigence attendu.

Une ESN peut aider à formuler, structurer et challenger. Mais elle ne peut pas inventer seule la stratégie produit du client.

Quand cette distinction n'est pas claire, le projet démarre avec une attente implicite : le prestataire devrait comprendre seul ce qui compte vraiment, même quand ce n'est pas exprimé clairement.

C'est souvent le début des malentendus.

Le client n'a pas besoin d'être technique, mais il doit rester impliqué

C'est précisément parce que le client n'a pas toujours les compétences techniques en interne qu'il fait appel à une ESN.

Mais cela ne veut pas dire que la technique devient un sujet totalement extérieur à l'entreprise.

Un choix d'architecture peut conditionner la capacité à faire évoluer le produit.
Une dette technique peut ralentir la roadmap.
Une mauvaise gestion des droits peut créer un risque métier.
Une stratégie de tests insuffisante peut fragiliser les mises en production.
Une intégration mal pensée peut bloquer un futur partenariat.

Ces décisions concernent directement le client, même s'il n'a pas les compétences pour les évaluer seul.

Le sujet n'est donc pas que le client devienne technique. Le sujet est qu'il ne laisse pas des décisions structurantes se prendre sans lui, simplement parce qu'elles sont exprimées dans un langage technique.

Faut-il faire vite ou faire durable ?
Faut-il absorber ce changement maintenant ou revoir le périmètre ?
Faut-il accepter une dette temporaire pour tenir une date ?
Faut-il simplifier une fonctionnalité pour préserver le budget ?
Faut-il construire pour six mois ou pour trois ans ?

Ces questions ne peuvent pas être tranchées uniquement par les développeurs.

Elles demandent une décision client : budget, délai, qualité, ambition produit, risque acceptable.

Quand personne ne traduit ces questions, l'équipe technique de l'ESN prend des décisions par défaut. Parfois avec sérieux. Parfois avec bon sens. Mais sans toujours avoir le contexte métier, stratégique ou financier nécessaire.

Le client pense avoir délégué la technique.

En réalité, il a parfois délégué sans le vouloir une partie de ses arbitrages produit.

Une ESN travaille avec ses propres contraintes

Pour comprendre les tensions, il faut aussi regarder le modèle de l'ESN sans caricature.

Une ESN n'est pas une équipe produit interne. Elle intervient dans un cadre contractuel, avec un périmètre, un budget, une marge, des profils disponibles, une organisation commerciale et des engagements à tenir.

Ces contraintes ne sont pas forcément des défauts. Ce sont des contraintes de modèle.

Mais si elles ne sont pas comprises, elles créent de la frustration.

Une ESN peut avoir du mal à challenger fortement un client qui paie. Elle peut hésiter à dire trop tôt qu'une demande est floue, risquée ou mal priorisée. Elle peut rester dans le périmètre vendu, même si le besoin réel dépasse ce cadre. Elle peut privilégier la production visible, parce que c'est ce qui rassure en comité projet.

Il faut aussi rappeler que toutes les ESN ne se valent pas.

Certaines ont une vraie culture produit et technique. Elles savent alerter tôt, documenter leurs choix, challenger utilement et reconnaître un risque avant qu'il devienne coûteux.

D'autres sont plus orientées exécution, staffing ou engagement de moyens. D'autres encore ont de bons développeurs, mais un pilotage technique trop faible.

Le client doit donc comprendre ce qu'il achète réellement.

Achète-t-il une capacité de développement ? Une équipe autonome ? Un engagement de résultat ? Un accompagnement produit ? Une expertise d'architecture ? Un pilotage technique ? Une simple force d'exécution ?

Ces différences changent tout.

Quand le client pense acheter du conseil stratégique alors que le prestataire vend surtout de la réalisation, la déception est presque programmée.

Les zones grises font plus de dégâts que les désaccords explicites

Un désaccord clair peut se traiter.

On peut arbitrer un budget.
On peut revoir une priorité.
On peut décaler une date.
On peut réduire un périmètre.
On peut changer une approche technique.

Le vrai risque vient souvent des zones grises.

Ce sont les sujets que personne ne formule vraiment. Les décisions que tout le monde croit comprises. Les risques que l'équipe technique voit, mais qui ne remontent pas clairement côté client. Les attentes métier qui semblent évidentes pour le client, mais qui ne le sont pas pour l'équipe de réalisation.

On entend alors des phrases révélatrices :

C'était évident pour nous.

Ce n'était pas dans le périmètre.

Techniquement, ce n'est pas si simple.

Pourquoi personne ne nous l'a dit plus tôt ?

On pensait que c'était inclus.

On a livré ce qui était demandé.

Oui, mais ce n'est pas ce dont on avait besoin.

Ces phrases montrent souvent qu'un sujet important n'a pas été assez clarifié : le besoin réel, le périmètre, le risque technique ou la décision attendue.

Prenons un exemple simple.

Le client demande un tableau de bord pour suivre l'activité commerciale. L'ESN chiffre et développe plusieurs écrans avec des filtres, des graphiques et des exports.

Au moment de la recette, le client réalise que les chiffres ne sont pas calculés comme il l'imaginait. Certaines opportunités sont incluses, d'autres non. Les règles de regroupement ne correspondent pas à la façon dont les équipes pilotent réellement leur activité.

L'ESN répond qu'elle a appliqué les règles décrites.

Et c'est peut-être vrai.

Mais le vrai besoin n'était pas seulement "afficher un tableau de bord". Le vrai besoin était "permettre à une équipe commerciale de prendre des décisions fiables chaque semaine".

La différence semble subtile. Elle ne l'est pas.

Dans le premier cas, on livre une fonctionnalité.
Dans le second, on sécurise un usage métier.

Entre les deux, il faut poser des questions, clarifier les règles, comprendre les décisions que le tableau doit permettre, identifier les données critiques et signaler les limites.

Si personne ne joue ce rôle, le projet avance. Mais il avance sur une compréhension fragile.

Les comités projet parlent souvent du planning, pas assez des risques

Un autre signal faible apparaît dans beaucoup de projets externalisés : les comités projet deviennent des réunions de suivi, mais pas de décision.

On passe en revue les tickets terminés.
On regarde la charge consommée.
On commente le planning.
On liste les points ouverts.

Tout cela est utile. Mais ce n'est pas suffisant.

Un projet logiciel ne dérape pas seulement parce qu'une tâche prend plus de temps que prévu. Il dérape aussi parce que certains risques ne sont pas traduits au bon niveau.

Un développeur peut voir qu'un module devient difficile à maintenir. Un architecte peut sentir qu'un choix d'intégration est fragile. Un product owner peut constater que les priorités changent trop souvent. Un utilisateur clé peut signaler que le produit ne colle pas aux usages réels.

Mais si ces signaux restent dispersés, ils ne produisent aucune décision.

Le comité projet entend alors des formulations trop vagues :

Il y a un peu de dette.

Ce sujet est plus complexe que prévu.

On verra dans un second temps.

Ce n'est pas bloquant pour l'instant.

Pour un dirigeant, un fondateur ou un responsable métier, ces phrases ne suffisent pas.

Il a besoin de comprendre l'impact.

Est-ce que cela menace la date de lancement ? Est-ce que cela augmente le coût de maintenance ? Est-ce que cela rendra certaines évolutions plus lentes ? Est-ce que cela crée une dépendance forte à un prestataire ?

C'est là que la traduction technique devient essentielle.

Un risque technique mal formulé reste un bruit de fond.
Un risque technique traduit en impact métier devient un sujet d'arbitrage.

L'agilité donne de la souplesse, mais elle ne rend pas les changements gratuits

Beaucoup de projets confiés à une ESN sont pilotés avec des rituels agiles : sprints, démonstrations régulières, backlog, priorisation continue, retours fréquents.

Sur le papier, c'est une bonne chose.

L'agilité permet au client de voir le produit avancer. Elle évite d'attendre six mois avant de découvrir un mauvais choix. Elle permet de tester tôt, d'ajuster une priorité, de simplifier un besoin ou de revoir une hypothèse.

Mais cette souplesse a une contrepartie souvent sous-estimée.

Pour fonctionner, l'agilité demande une forte implication du client. Il doit tester régulièrement, faire des retours précis, arbitrer vite et accepter que chaque changement puisse avoir un impact sur le budget, le planning, la qualité ou l'architecture.

C'est là que beaucoup de tensions apparaissent.

Côté métier, une demande peut sembler simple :

C'est juste un petit changement.

Mais ce "petit changement" peut toucher une règle structurante, modifier le modèle de données, casser une hypothèse d'architecture, complexifier les droits utilisateurs ou rendre certains tests obsolètes.

Dans l'interface, le changement paraît minime.
Dans le code, il peut être profond.

Le problème n'est pas que le métier demande des ajustements. C'est normal. C'est même l'un des intérêts d'un fonctionnement agile.

Le problème apparaît quand ces ajustements sont acceptés sans analyse d'impact.

Si le périmètre augmente, il faut généralement accepter au moins une conséquence : augmenter le budget, repousser une échéance, réduire d'autres fonctionnalités, simplifier la demande, accepter une dette temporaire ou revoir l'ambition de la version livrée.

Si aucune de ces variables ne bouge, c'est souvent la qualité qui absorbe le choc.

Et la qualité ne se plaint pas tout de suite.

Elle se dégrade lentement. Elle rend les évolutions plus longues. Elle augmente les régressions. Elle fatigue les équipes. Elle rend le produit plus difficile à reprendre.

L'agilité fonctionne bien quand elle aide à apprendre vite et à décider mieux.

Elle fonctionne mal quand elle devient une excuse pour changer souvent sans jamais arbitrer clairement.

Le référent technique côté client n'est pas un contrôleur anti-ESN

Quand on parle d'ajouter un référent technique côté client, certaines ESN peuvent se crisper.

Elles peuvent y voir une forme de surveillance, une remise en cause de leur compétence ou un risque de ralentir les décisions.

Cette crainte peut se comprendre, surtout si le rôle est mal présenté.

Mais ce n'est pas le bon positionnement.

Le rôle d'un expert technique côté client n'est pas de mettre l'ESN sous surveillance. C'est de permettre une collaboration plus claire, plus saine et plus maîtrisée.

Il ne vient pas faire la guerre à l'ESN.
Il ne vient pas micro-manager les développeurs.
Il ne vient pas imposer une perfection théorique.
Il ne vient pas transformer le projet en audit permanent.

Il vient surtout rendre le delivery plus lisible.

Concrètement, il aide à clarifier les responsabilités, rendre les compromis explicites, traduire les risques techniques, challenger les choix structurants et préparer les arbitrages côté client.

Dans certains cas, ce rôle peut être porté par un responsable technique externalisé. Dans d'autres, par un lead developer freelance, un CTO part-time, un architecte ou un profil de conseil technique habitué aux contextes produit.

Le titre importe moins que la posture.

Il faut quelqu'un qui comprenne la technique, mais aussi le produit, les contraintes d'une ESN, les enjeux de budget et la réalité du delivery.

Un profil trop théorique va bloquer sur des principes.
Un profil trop opérationnel risque de descendre trop bas dans le détail.
Un profil trop "contrôle qualité" peut créer une relation défensive.

Le bon équilibre consiste à intervenir sur les sujets qui ont un impact durable : architecture, dette technique, maintenabilité, cadrage, priorisation, dépendances, risques, qualité et trajectoire produit.

Un bon accompagnement protège aussi l'ESN

On présente souvent l'accompagnement technique côté client comme une protection pour le client.

C'est vrai, mais incomplet.

Un bon accompagnement protège aussi l'ESN.

Il la protège contre les demandes implicites, les changements de priorité non arbitrés, les attentes floues, les reproches tardifs sur des sujets jamais clarifiés et les décisions métier repoussées puis transformées en urgence technique.

Une ESN travaille mieux quand le client sait décider.

Et un client décide mieux quand il comprend les impacts techniques de ses choix.

Quand un référent technique côté client fait bien son travail, les échanges deviennent plus simples. Les alertes sont mieux formulées. Les arbitrages arrivent plus tôt. Les décisions sont mieux documentées. Les limites de périmètre sont plus explicites.

Cela ne supprime pas tous les désaccords.

Mais cela évite que chaque désaccord devienne une crise de confiance.

Exemple fréquent : une fonctionnalité demandée en cours de projet semble "petite" côté client. Pour l'ESN, elle implique de revoir une partie du modèle de données, d'adapter des écrans existants, de modifier des tests et de reprendre une API déjà utilisée ailleurs.

Sans traduction, la discussion se bloque.

Le client pense : "Ils exagèrent."
L'ESN pense : "Ils ne comprennent pas."

Avec un référent technique côté client, le sujet peut être reformulé autrement :

La demande paraît simple dans l'interface, mais elle touche une règle structurante du produit. On peut la faire maintenant, mais cela consomme une partie du budget et augmente le risque sur la date. Sinon, on peut livrer une version limitée, puis traiter le cas complet après la mise en production.

Cette reformulation permet de décider.

Ce n'est plus un débat technique.
Ce n'est plus une négociation floue.
C'est un arbitrage.

Les signes qu'un projet externalisé manque de clarté technique

Plusieurs signaux doivent alerter.

Les mêmes sujets reviennent à chaque comité, sans décision nette. On parle d'un point pendant trois semaines, puis il réapparaît sous une autre forme. Souvent, le vrai arbitrage n'a pas été posé.

Les développeurs avancent, mais le client découvre tardivement des comportements importants. La recette devient alors une phase de clarification, alors qu'elle devrait surtout valider ce qui a déjà été compris.

Les choix techniques sont présentés comme des évidences : "On a fait comme ça parce que c'est plus simple." "C'est le standard." "C'est plus rapide." Ces réponses peuvent être valables, mais elles doivent être reliées au contexte du projet.

La dette technique existe, tout le monde en parle, mais personne ne sait vraiment la qualifier. Est-elle gênante ? Dangereuse ? Acceptable ? Temporaire ? Structurelle ? Sans qualification, elle ne sert à rien dans la décision.

Les alertes arrivent sous forme de surprise. Un problème technique devient visible seulement quand il bloque une livraison, alors qu'il aurait pu être signalé plus tôt comme risque probable.

Enfin, l'agilité sert surtout à ajouter des demandes, rarement à retirer du périmètre. Le backlog grossit, les priorités changent, mais le budget et le planning restent présentés comme stables.

Ces signaux ne signifient pas forcément que l'ESN travaille mal.

Ils signifient que le pilotage technique côté client est insuffisant.

Dans une startup SaaS, une PME produit ou un projet entrepreneurial, ce manque de visibilité peut coûter cher. Surtout quand le produit commence à prendre de l'importance dans l'activité.

Quand faire intervenir un responsable technique externalisé ?

Le bon moment n'est pas seulement celui où le projet va mal.

C'est même souvent trop tard.

Un responsable technique externalisé peut intervenir avant de choisir une ESN, pendant le cadrage, au lancement du projet, à un jalon critique ou lorsqu'un doute apparaît sur la trajectoire.

Avant de choisir une ESN, il peut aider à clarifier le besoin, relire une proposition, identifier les zones floues et vérifier que le niveau d'accompagnement vendu correspond vraiment au besoin.

Pendant le cadrage, il peut aider à distinguer ce qui relève du produit, de la technique, du budget, du délai ou du risque.

Pendant le delivery, il peut participer aux points clés, relire les choix structurants, challenger les alertes, aider à prioriser et préparer les arbitrages côté client.

Lorsqu'un projet se tend, il peut réaliser un audit technique ciblé pour comprendre ce qui relève d'un problème de qualité, de cadrage, d'organisation, de périmètre ou de communication.

Après une première livraison, il peut préparer la suite : reprise en interne, changement de prestataire, structuration d'une équipe, amélioration de la qualité, réduction de dette technique ou stabilisation produit.

Dans un écosystème local, ce besoin apparaît souvent chez des dirigeants ou équipes produit qui cherchent du conseil technique à Lyon, un lead developer freelance à Lyon ou un responsable technique externalisé capable d'intervenir sans prendre toute la place.

Ce rôle n'a pas besoin d'être permanent pour être utile.

Parfois, quelques jours bien placés valent mieux que des mois de pilotage flou.

Ce qu'il faut clarifier dès le départ

Pour éviter les malentendus, certains sujets doivent être rendus explicites tôt.

Une grille simple aide souvent à éviter les malentendus :

Le mot "qualité" ne suffit pas.

Un projet peut être livré dans les temps et rester fragile. Un produit peut fonctionner en démonstration et être difficile à maintenir. Une fonctionnalité peut passer la recette et créer de la dette.

Une alerte technique ne doit donc pas rester bloquée dans un ticket. Elle doit être reformulée en impact, en options et en décision attendue.

Par exemple :

Nous avons identifié un risque sur la gestion des droits. Si nous gardons l'approche actuelle, la V1 peut sortir plus vite, mais les évolutions multi-rôles prévues au prochain trimestre seront coûteuses. Nous recommandons soit de limiter le besoin en V1, soit de revoir maintenant le modèle d'autorisation.

Cette manière de formuler change tout.

Elle permet au client d'exercer sa responsabilité sans devoir devenir expert technique.

Conclusion : le sujet n'est pas de contrôler, mais de rendre les décisions possibles

Un projet confié à une ESN peut très bien se passer.

Mais il ne se pilote pas tout seul.

Externaliser le développement ne supprime pas la responsabilité du client. Travailler en agile non plus. Dans les deux cas, la responsabilité change de forme : le client n'a pas à piloter chaque détail technique, mais il doit rester disponible pour tester, prioriser, arbitrer et comprendre les conséquences de ses changements.

De son côté, l'ESN peut conseiller, alerter et structurer, mais elle travaille toujours dans un cadre donné : contrat, budget, périmètre, planning et niveau de contexte disponible.

Entre les deux, il faut un espace de traduction.

C'est là qu'un responsable technique externalisé côté client prend tout son sens.

Son rôle n'est pas de contrôler l'ESN.
Son rôle est de remettre de la clarté entre les deux.

Clarifier les responsabilités, anticiper les risques, challenger les choix structurants, traduire la technique en arbitrages métier : tout cela sert un objectif simple.

Faire en sorte que les bonnes décisions soient prises assez tôt, par les bonnes personnes, avec les bons impacts visibles.

Vous confiez un projet à une ESN ?

Quand un projet avec une ESN démarre, se tend ou arrive à un jalon important, il est utile de remettre à plat les responsabilités, les risques et les arbitrages.

Axons intervient côté client pour relire un cadrage, challenger une proposition, sécuriser les choix techniques et rendre le pilotage plus lisible entre les équipes métier, la direction et l'ESN.

Contactez-moi pour en parler.