Ce que votre CODIR attend d'un projet SI et ce que votre prestataire livre
Le CODIR attend un impact business. Le prestataire livre des fonctionnalités. Ce fossé n'est pas accidentel : il est structurel. Sans mécanisme explicite pour combler l'écart, les revues de projet deviennent des rapports d'avancement technique que personne ne traduit en langage de direction.
Donatien Lefranc
Fondateur & Président, Leando
La réunion de pilotage où tout le monde parle du même projet mais pas de la même chose
La scène est reconnaissable. Le prestataire présente l'avancement du projet : quatre-vingt pour cent des fonctionnalités sont livrées, les tests sont en cours, la mise en production est planifiée dans trois semaines. Le directeur général écoute et pose une question simple : « est-ce que ça va résoudre notre problème de délais de contractualisation ? » Silence. Puis une réponse sur la fonctionnalité, pas sur le problème.
Cette scène n'est pas un échec de communication. C'est le résultat prévisible d'une divergence de référentiels qui n'a jamais été traitée. Le prestataire mesure le succès en livrables fonctionnels. Le CODIR mesure le succès en impact sur les processus ou les résultats. Les deux mesures ne se recoupent pas naturellement. Elles se recoupent uniquement si quelqu'un fait le travail de traduction explicitement.
Ce travail de traduction n'est pas dans le périmètre standard d'une agence ou d'un prestataire. Ce n'est pas non plus dans les habitudes du CODIR, qui délègue généralement le projet à un chef de projet interne. Entre les deux, personne ne fait la jonction.
Pourquoi le fossé est structurel, pas accidentel
Un prestataire construit ses indicateurs de pilotage autour de ce qu'il maîtrise : le périmètre technique, les délais, le budget. Ces indicateurs sont légitimes. Ils ne disent rien sur l'impact business. Ce n'est pas un manque de bonne volonté : le prestataire n'a pas accès aux métriques business de son client, et même s'il les avait, il ne contrôle pas les variables qui les déterminent (adoption des équipes, organisation des processus, qualité des données).
De son côté, le CODIR formule souvent ses attentes en termes de résultats attendus (« réduire les délais de facturation », « libérer du temps aux commerciaux »), sans les décliner en critères de validation technique. Ces attentes restent dans les présentations de lancement et ne réapparaissent jamais dans les revues de projet hebdomadaires.
Le résultat : un projet peut être livré dans les délais, dans le budget, avec toutes les fonctionnalités validées, et produire une déception côté direction.Pas parce que le prestataire a mal travaillé. Parce que personne n'a défini en amont ce que « réussite » signifiait en termes business, ni comment le mesurer.
« Ce qu'ils apprécient très fortement avec nous, c'est qu'on était là à la fois pour se poser les bonnes questions dans leur métier et à la fois prendre les décisions qu'ils n'arrivaient pas à prendre eux-mêmes. On n'est pas là pour délivrer du code. Notre valeur, c'est la capacité à poser les bonnes questions, à structurer la manière d'avancer et à prendre les bonnes décisions. »
Ce fossé se voit particulièrement dans les projets où le premier prestataire a livré du code mais pas de structure. La situation qui se répète : ce que les freelances livrent et ce qui manque systématiquement.
Trois mécanismes pour combler l'écart entre direction et prestataire
Formuler les critères de succès en résultats business avant de les formuler en livrables. Cela se fait en deux temps. D'abord, le CODIR formule ce qu'il veut obtenir (« réduire le délai de contractualisation de cinq jours à deux »). Ensuite, le prestataire et l'équipe projet identifient les fonctionnalités qui contribuent à cet objectif. Cette séquence inverse la logique habituelle : ce n'est plus la fonctionnalité qui détermine l'impact attendu, c'est l'impact attendu qui détermine les fonctionnalités à prioriser.
Intégrer un jalon business dans chaque revue de projet. La revue standard d'un prestataire couvre le périmètre livré, les bugs ouverts et le planning. Ajouter un jalon business signifie demander explicitement : « qu'est-ce que ce sprint a changé dans le quotidien des équipes ? » Si la réponse est « rien encore, la mise en production n'est pas faite », le jalon peut porter sur les retours des utilisateurs pilotes ou les scénarios de recette réalisés. L'objectif n'est pas de changer le rythme de livraison. C'est de maintenir le lien entre ce qui est construit et ce qui est attendu.
Nommer un interlocuteur capable de faire la traduction dans les deux sens. Ni le prestataire seul, ni le CODIR seul. Quelqu'un qui comprend les contraintes techniques et qui peut les exprimer en termes d'impact business pour la direction. Dans les projets bien menés, ce rôle est tenu par un chef de projet côté client avec une culture technique suffisante, ou par un partenaire externe dont c'est la posture habituelle. Pour comprendre comment ce rôle se construit : le pont métier/tech et la traduction bidirectionnelle.
BKW Énergie France : les décisions que la direction n'arrivait pas à prendre
Chez BKW Énergie France (filiale d'un groupe suisse), la première tentative en 2025 avec des freelances avait produit exactement ce fossé : du code livré selon les spécifications, sans vision d'ensemble sur l'impact opérationnel. Les freelances avaient bien travaillé dans leur périmètre. Personne n'avait fait le lien entre ce périmètre et les attentes du directeur général Ulrich et du DSI Olivier.
Ce que Leando a apporté n'était pas technique. C'était la capacité à parler au DG de sa vision, aux équipes terrain de leur quotidien, et à l'équipe technique de l'architecture. Et à faire circuler l'information entre ces trois niveaux de manière cohérente. Olivier et Ulrich ont identifié cet apport comme le premier de la collaboration : « ils étaient là pour se poser les bonnes questions dans notre métier et prendre les décisions qu'on n'arrivait pas à prendre nous-mêmes. »
Ce rôle, celui qui débloque les décisions que l'interne n'arrive pas à prendre, est rarement dans le contrat d'une agence ou d'un prestataire classique. Il n'est pas dans les specs. Il produit pourtant souvent plus de valeur que les fonctionnalités elles-mêmes. Pour voir comment ce déblocage se produit : les décisions que l'interne n'arrive pas à prendre et ce qu'un regard externe débloque.
La question à poser avant votre prochaine revue de projet
Avant la prochaine réunion de pilotage, posez cette question à votre équipe projet : « si le projet s'arrêtait demain dans son état actuel, est-ce que la direction considérerait que ça valait l'investissement ? »
Si la réponse est « non, pas encore, les fonctionnalités importantes ne sont pas là » : la question porte sur la priorisation du périmètre. Si la réponse est « on ne sait pas, on n'a pas les critères pour le mesurer » : la question porte sur l'alignement des attentes. Si la réponse est « oui, mais la direction ne le voit pas encore » : la question porte sur la communication et le pilotage.
Chacune de ces réponses appelle une action différente. Ce qui est certain, c'est qu'une réunion de pilotage qui ne permet pas de répondre à cette question produit un projet qui avance techniquement et stagne en termes d'impact. Et un projet qui stagne en termes d'impact finit toujours par décevoir, quel que soit le niveau de qualité technique des livrables.
Parce que leurs référentiels de succès sont différents par construction. Le prestataire mesure le succès en fonctionnalités livrées dans les délais et le budget. Le CODIR mesure le succès en impact sur les processus, la productivité ou le CA. Ces deux mesures ne se recoupent que rarement sans un travail explicite de traduction entre elles.
Votre direction et votre prestataire parlent-ils le même langage ?
Un entretien de cadrage avec votre CODIR et votre équipe projet permet d'aligner les critères de succès avant que le fossé ne se creuse. Trente minutes suffisent pour identifier où se situe le désalignement.
Cadrer mon projet SI