Travailler avec une ESN, côté client, commence souvent bien : une équipe arrive vite, compétente, et le projet démarre. Les ennuis viennent plus tard, quand on découvre que personne en interne ne sait plus pourquoi telle règle a été codée de cette façon, que la spécification a trois versions en circulation, ou que la fin du contrat signifie la fin de toute connaissance du système.
Je pilote des projets tech depuis une vingtaine d'années, en maîtrise d'ouvrage comme en maîtrise d'œuvre, et je me retrouve souvent entre un client et ses prestataires techniques. Je ne fais pas moi-même de régie longue, d'infogérance ni de refonte d'ERP : ce sont des terrains où une entreprise de services du numérique (ESN) a toute sa place. Voici ce que je pose pour que le client garde la main, et les limites de l'exercice.
01Ce qu'une ESN vend : du temps ou un résultat
La première question n'est pas « quelle ESN ? » mais « qu'est-ce que j'achète ? ». Il y a deux grands modes, et ils ne font pas porter le risque au même endroit.
En régie, vous achetez du temps de compétence. Des consultants travaillent sur votre projet, facturés au temps passé. Si le résultat tarde, vous payez quand même. C'est souple quand le besoin bouge, mais c'est vous qui portez le risque, et donc vous qui devez piloter.
Au forfait, l'ESN s'engage sur un livrable, un délai et un montant. Mike Clayton, qui forme des chefs de projet, le résume dans sa vidéo sur les contrats au forfait : tout est affaire de risque. Le prestataire porte les dépassements, le client gagne la certitude financière, mais paie une prime pour ce risque. Il met aussi en garde contre le client qui veut un montant à la fois fixe et bas.
Ma règle est simple : le forfait seulement si je peux écrire le besoin et les critères de recette avant de commencer. Sinon, la régie, avec un pilotage serré, ou un découpage en petits forfaits successifs.
02Ce que vous ne déléguez pas
Une ESN peut tout construire. Elle ne peut pas décider à votre place de ce qui a de la valeur. Le Scrum Guide le dit pour le Product Owner : il peut déléguer le travail, mais il reste responsable, et c'est une personne, pas un comité. Je garde cette idée même hors de Scrum. Quelqu'un chez le client tranche les priorités, et toute l'organisation respecte ses arbitrages.
Le manuel des services publics britanniques va dans le même sens : les personnes qui prennent les décisions font partie de l'équipe et lui rendent des comptes, et le travail avec des prestataires extérieurs doit se faire sur une base durable.
Concrètement, je ne délègue jamais trois choses : l'ordre des priorités, la donnée de référence (quel outil fait foi pour une fiche produit, un stock, un client) et l'acceptation en recette. Le jour où l'ESN décide seule de ce qui est « fini », vous ne pilotez plus rien.
03Le cadre à poser avant le premier jour
C'est la partie la moins visible et celle qui évite le plus d'ennuis. Je la traite comme une checklist, à cocher avant que le premier consultant ne touche au code.
Le contrat et les données
Si l'ESN manipule des données personnelles (clients, salariés, utilisateurs), elle est sous-traitant au sens du RGPD. La CNIL est nette : ne pas commencer une prestation sans contrat reprenant l'article 28 du RGPD. Ce contrat règle la répartition des responsabilités, la restitution et la destruction des données en fin de contrat, et la notification des incidents. La CNIL demande aussi de regarder toute la chaîne : les sous-traitants de votre sous-traitant comptent.
Les accès
Le même manuel britannique demande de ne donner aux prestataires que les accès dont ils ont besoin, et de prévoir comment les retirer. J'ajoute une liste tenue à jour : qui a accès à quoi, depuis quand, avec quel compte. Les comptes partagés « équipe ESN » sont à proscrire, on ne sait plus qui a fait quoi.
Le document de référence
Une spécification que tout le monde lit, versionnée et datée. Sur une intégration entre un ERP et un site marchand, la spécification a bougé presque à chaque réunion. Je l'ai fait évoluer version après version, pour que tout le monde parle du même document. J'en ai tiré une méthode pour écrire une spécification d'intégration. Avec une ESN, c'est encore plus utile : la version signée est celle qu'on facture.
Les critères de recette
Écrits avant le développement, pas après la livraison. Je m'appuie sur ma checklist de recette et de mise en production. Un point que j'y garde toujours : un site peut sembler normal à l'équipe connectée et être cassé pour les visiteurs, à cause du cache. La recette se fait donc aussi comme un visiteur, déconnecté.
04Piloter une ESN au quotidien sans faire le chef d'équipe
Piloter une ESN ne veut pas dire diriger ses consultants comme vos salariés. Il y a une raison pratique et une raison juridique.
La raison pratique : si vous distribuez les tâches une par une, vous refaites le travail de l'ESN, vous en prenez le risque, et vous payez deux fois l'encadrement.
La raison juridique : le ministère du Travail rappelle que le code du travail interdit, sauf exceptions, toute opération à but lucratif ayant pour objet exclusif le prêt de main-d'œuvre, et que l'utilisateur de cette main-d'œuvre peut être sanctionné, pas seulement le fournisseur. Je ne suis pas juriste, et la frontière se discute avec le vôtre. Mais je retiens une règle de conduite : vous exprimez un besoin et vous validez un résultat ; l'organisation du travail des consultants reste à l'ESN.
Ce qui marche, à mon expérience, c'est un rythme fixe plutôt qu'une présence permanente :
- un point court chaque semaine avec le responsable côté ESN, sur ce qui est fini, ce qui bloque et ce qui est en attente d'une décision ;
- un rapport mensuel qui part seul, toujours au même format, avec l'avancement, le temps consommé et les risques ;
- un comité de pilotage qui décide vraiment, une fois par mois, avec la personne qui tranche les priorités.
Un rapport mensuel qui part seul et un comité qui décide valent mieux qu'un tableau de bord qu'on ne lit pas. Dans mes propres machines de contenu, j'applique la même idée aux retours : une correction qui revient deux fois devient une règle écrite. Avec une ESN, c'est pareil. Un défaut récurrent en recette devient un critère écrit, pas une remarque de plus en réunion.
05Préparer la sortie dès l'entrée
Le passage le plus utile du manuel britannique sur les prestataires est celui-ci : ne travailler qu'avec des prestataires prêts à transmettre leur savoir, et avoir un plan de transfert de connaissances, surtout quand on change de prestataire. Le texte propose des binômes entre consultants et internes, des sessions de partage et une documentation tenue à jour.
Je le traduis en trois exigences écrites dès le contrat :
- le code et la documentation vivent dans vos outils (dépôt, wiki), sous vos comptes, pas chez l'ESN ;
- chaque livraison importante s'accompagne d'une note courte : ce qui a changé, pourquoi, comment le vérifier ;
- quelqu'un en interne suit le projet d'assez près pour poser les bonnes questions le jour où l'équipe change.
C'est aussi ma façon de travailler sur mes propres missions : courtes, avec une transmission documentée à la fin. Je ne vois pas pourquoi on l'exigerait moins d'une équipe de dix personnes.
06Quand une ESN n'est pas le bon choix
L'ESN n'est pas la réponse par défaut. Elle convient mal à trois situations.
Quand le besoin n'est pas encore clair, d'abord. Mettre une équipe en régie sur un projet flou, c'est payer cher pour découvrir ce qu'on voulait. Je préfère cadrer le projet en une semaine, avec un prototype si besoin, puis consulter.
Quand personne en interne ne peut piloter, ensuite. Sans interlocuteur qui décide, même une très bonne ESN finit par définir elle-même les priorités, et ce ne sont pas forcément les vôtres.
Quand le projet est petit, enfin. Le coût de coordination d'une équipe pèse lourd sur quelques semaines de travail. Une personne qui conçoit et construit peut aller plus vite. C'est mon cas, avec ses limites : je ne remplace pas une équipe pour exploiter un système en continu.
Et une limite de ma méthode elle-même : tout ce cadre demande du temps côté client, surtout au début. Si vous ne pouvez pas y consacrer quelques heures par semaine, il faut le savoir avant de signer.
07Par où commencer lundi
Si vous travaillez déjà avec une ESN, prenez une heure pour vérifier quatre points : le contrat de sous-traitance des données existe, la liste des accès est à jour, la spécification en vigueur a un numéro de version, et quelqu'un en interne sait qui tranche les priorités. Ce qui manque devient l'ordre du jour du prochain point.
Si vous allez en choisir une, écrivez d'abord le besoin et les critères de recette, puis décidez entre régie et forfait en sachant qui porte le risque. Ce travail en amont fait partie de ce que je propose dans mes services, et le portfolio montre les projets où je l'ai fait. Si votre situation ne rentre dans aucune de ces cases, on peut en parler.