Quand la structuration finit par compliquer le delivery

J'ai passé une grande partie de ma carrière dans des entreprises de logiciels et de services. J'ai connu la phase où une poignée de personnes compétentes livrent des projets de bout en bout, et celle où l'organisation, devenue plus grande, se met en place pour mieux contrôler, standardiser et prévoir. Dans la théorie, cette structuration est une avancée. Dans la pratique, je l'ai vue produire parfois l'effet inverse : plus de personnes mobilisées, plus d'interfaces, plus de contrôle, et pourtant un delivery qui ne va pas mieux.

Ce n'est pas une critique de la structuration en soi. Une entreprise qui grandit ne peut pas rester indéfiniment sur un fonctionnement artisanal. Mais il existe une zone de risque, fréquente dans les sociétés de taille intermédiaire, où l'organisation conçue pour maîtriser les projets finit par les alourdir. C'est cette zone que je veux décrire ici, avec le recul de quelqu'un qui a été à la fois dans le delivery et dans les postes de direction.

Quand un petit projet hérite d'une grande organisation

Sur un projet de 100 à 150 jours, une structure simple peut être remarquablement efficace. Une personne expérimentée porte le delivery, comprend le besoin du client, garde une vision de bout en bout et sollicite ponctuellement d'autres experts. Elle sait à la fois vendre l'idée, concevoir la solution, l'implémenter et la faire accepter. Ce n'est pas une question de talent surhumain : c'est une question de continuité. Quand la même personne voit le projet naître, vivre et se déployer, elle en maîtrise les tensions et les imprévus.

À mesure que l'entreprise se structure, les rôles se multiplient. Chef de projet, consultant fonctionnel senior, consultants fonctionnels d'exécution, consultant technique principal, consultants techniques, experts, responsables de practice ou de delivery. Chaque rôle a sa logique. Le problème n'est pas le nombre de personnes. Le problème est la dilution de la responsabilité et de la compétence.

On observe alors une séquence classique. Le chef de projet pilote mais ne délivre plus. Celui qui a conçu n'exécute plus. Celui qui exécute n'a parfois qu'une vision partielle du besoin. Lorsqu'une difficulté apparaît, il faut remonter plusieurs niveaux pour retrouver la compétence ou la décision. Et plus on remonte, plus la personne qui décide est éloignée de la situation réelle.

Les experts retirés du delivery

Très souvent, les meilleurs experts finissent regroupés dans des pôles d'expertise. Ils n'interviennent plus tout au long du projet mais essentiellement lorsque le problème est déjà là, presque en mode pompier. Cette séparation a des vertus : elle permet de centraliser des compétences rares et de les affecter là où elles sont vraiment nécessaires. Mais elle a un effet secondaire puissant.

Ces experts sont fréquemment ceux qui, auparavant, savaient porter eux-mêmes des projets de bout en bout. En les éloignant du delivery quotidien, l'entreprise se prive du meilleur moyen de faire monter en compétence les consultants qui doivent progressivement les remplacer. La transmission ne se fait plus en marchant ensemble sur des cas réels. Elle se réduit à des formations, des revues de cas ou des interventions ponctuelles. La théorie est transmise, mais la pratique, la nuance, l'art de gérer un client sous pression, tout cela ne se déplace pas de la même manière.

Au bout de quelques années, l'entreprise se retrouve avec une population senior qui diagnostique et une population junior qui exécute, sans la génération intermédiaire qui aurait dû apprendre en faisant. C'est un problème de plus en plus courant, et il touche particulièrement les entreprises qui ont grandi vite.

Le piège du temps facturable

Vouloir connaître précisément le coût réel de chaque projet est parfaitement légitime. Un dirigeant a besoin de savoir si une activité est rentable, où se situent les marges, et comment améliorer la performance. Le problème apparaît lorsque cette logique devient trop rigide.

Certaines organisations mettent en place des systèmes dans lesquels chaque heure doit être imputée, chaque intervention doit être justifiée, et le temps non facturable est considéré comme du temps sans valeur. Dans ce cadre, les collaborateurs hésitent à aider un collègue ou un autre projet parce que ce temps ne rentre pas dans le bon centre de coût. Ils reportent une demande plutôt que de la traiter en direct. Ils comptabilisent plutôt qu'ils ne coopèrent.

Tout ce qui n'est pas facturable n'est pas improductif.

Une organisation efficace repose aussi sur des échanges informels et transverses. Un expert qui débloque un collègue en vingt minutes. Un consultant qui partage une solution déjà testée. Un manager qui réalloue ponctuellement une ressource. Un responsable R&D qui aide le delivery. Un commercial qui apporte le contexte d'un client. Tous ces gestes ont une valeur réelle, mais une valeur difficile à rattacher à un projet précis. Si le système de contrôle les pénalise, ils disparaissent progressivement. Et ce qui disparaît avec eux, c'est la fluidité de l'entreprise.

Le pilotage financier doit mesurer le delivery. Il ne doit pas finir par concevoir le delivery. Le contrôle financier est indispensable, mais il devient contre-productif lorsqu'il rigidifie l'organisation au point d'empêcher les personnes de s'entraider ou d'arbitrer intelligemment.

La circulation entre Sales, Delivery, R&D et Support

Dans une entreprise de logiciels ou de services, de nombreuses situations se résolvent parce que les responsables Sales, Delivery, R&D et Support peuvent se parler directement. Le commercial comprend l'enjeu de la relation client. Le delivery connaît la réalité opérationnelle. La R&D sait ce qui est possible techniquement. Le support connaît l'historique et les difficultés rencontrées. Quand ces quatre regards se croisent librement, des problèmes qui auraient mis des semaines à remonter se règlent en une réunion, parfois en un échange informel.

Lorsque ces managers disposent de marges de manœuvre, ils peuvent résoudre rapidement une situation. Le problème apparaît lorsqu'une organisation trop contrôlée leur retire progressivement ces capacités d'arbitrage. Ils deviennent parfois responsables du résultat, mais n'ont plus la liberté de déplacer une ressource, de consacrer quelques heures à un problème, de solliciter un expert, d'accepter temporairement un coût interne ou d'adapter l'organisation d'un projet. Ils doivent alors escalader.

Et plus la décision remonte, plus elle peut être prise par des personnes éloignées de la situation réelle et travaillant principalement à partir d'indicateurs consolidés. Les indicateurs donnent une vue indispensable de l'entreprise. Mais ils ne remplacent jamais la connaissance fine d'une situation particulière. Le contrôle devient contre-productif lorsqu'il retire à ceux qui connaissent le mieux le problème la capacité de le résoudre.

On ne peut pas demander à un manager d'être responsable d'un résultat si on lui retire progressivement toutes ses capacités d'arbitrage.

Petit projet et grand projet

Il faut nuancer fortement ce que je viens de décrire. Je ne dis pas que le découpage des rôles est mauvais par nature. Sur des projets de 1 000, 2 000 ou 3 000 jours, la spécialisation est évidemment nécessaire. Il faut des chefs de projet, des spécialistes, des responsabilités distinctes, du contrôle, des méthodes, une gouvernance claire. Personne ne livre seul un projet de cette taille, et personne ne le souhaite.

Mais même sur de très grands projets, il faut conserver un fil de compétence transverse. Quelqu'un doit garder une compréhension suffisamment profonde du sujet pour reconnecter les différentes parties du projet. Cette personne n'est pas forcément le chef de projet. C'est parfois un architecte, un lead fonctionnel, un directeur de programme, un expert métier. L'essentiel est qu'elle existe.

Le problème n'est pas le découpage. C'est le découpage sans circulation. Une organisation peut être très segmentée et rester efficace à condition que l'information, la compétence et la décision puissent circuler entre les segments. C'est cette circulation qui fait la différence, pas l'absence de frontières.

La grande entreprise peut rester agile

Je ne veux pas opposer petite entreprise agile et grande entreprise bureaucratique. Cette opposition est trop facile et elle est fausse dans bien des cas. J'ai vu des petites structures lourdes et rigides, et des grandes entreprises capables de décider vite parce qu'elles avaient conservé les bons circuits.

Une grande entreprise peut parfaitement rester agile si elle conserve des circuits de décision courts, des managers responsabilisés, des échanges directs entre Sales, Delivery, R&D et Support, des experts accessibles, la possibilité de déroger intelligemment à certaines règles, et une culture où l'entraide n'est pas considérée comme une anomalie financière. La vraie opposition n'est pas entre petit et grand. Elle est entre organisation responsabilisante et organisation excessivement centralisée et contrôlée.

L'humain et le process

Un process est utile s'il facilite le travail, sécurise ce qui doit l'être et aide l'organisation à grandir. Il peut aussi devenir un refuge derrière lequel les individus se cachent. Ce n'est pas mon périmètre. Ce n'est pas imputable sur mon projet. Ce n'est pas mon rôle. Il faut faire remonter la demande. Ces phrases ne sont pas le signe d'une mauvaise volonté individuelle. Elles sont souvent le signe d'une organisation qui a fabriqué elle-même les comportements qu'elle voulait éviter.

Quand les règles deviennent plus importantes que le résultat, quand la conformité au process prime sur la résolution du problème, l'entreprise perd sa capacité d'adaptation. Elle se retrouve avec des collaborateurs qui savent parfaitement naviguer dans le système mais qui ont progressivement cessé de se demander si le système sert encore le client.

Les conséquences concrètes

Les dérives que je décris peuvent conduire à des résultats mesurables. Plus de personnes mobilisées sur un même projet. Davantage de jours consommés. Davantage d'interfaces à gérer. Une perte de transmission de compétence. Une dilution de la responsabilité. Des décisions plus lentes. Et au final, une qualité perçue par le client qui n'est pas meilleure, voire parfois moins bonne.

Le paradoxe est qu'une organisation construite pour mieux contrôler ses coûts peut parfois finir par coûter plus cher. Non pas parce que le contrôle est mauvais, mais parce qu'il a été poussé au point de remplacer le jugement par la règle, l'entraide par l'imputation, et la responsabilité par l'escalade.

Structurer n'est pas complexifier

Je ne conclurai pas qu'il faut supprimer les process ou revenir à une organisation artisanale. La structuration est indispensable à la croissance. Mais elle doit organiser la compétence, pas l'enfermer. Elle doit améliorer le contrôle, pas supprimer les marges de manœuvre. Elle doit clarifier les responsabilités, pas les diluer. Elle doit permettre la transmission de compétence. Et elle doit conserver la capacité de décision au plus près du terrain.

Le contrôle est utile. Mais lorsqu'il empêche les personnes compétentes de s'aider, de décider et de transmettre, il finit par coûter plus cher que ce qu'il cherche à économiser. C'est probablement la leçon que je retiens le plus fortement de ces années passées entre delivery et direction : la structure doit servir le jugement, pas le remplacer.