Le PDG comme middleware : comment les chaînes de validation deviennent le goulot de l'entreprise

Imaginons une commande de 12 000 € qui attend trois signatures. Une personne est indisponible ; une autre manque d’un élément absent du dossier. Le fournisseur ne peut pas réserver le stock indéfiniment. Cet exemple sert à examiner une file de décisions, sans prétendre décrire un résultat client.

Personne n'a conçu cette chaîne de validation. Elle a poussé. Chaque couche a été ajoutée pour une raison qui avait du sens sur le moment. Une mauvaise décision fournisseur en 2019. Une question de conformité qui a fait peur à quelqu'un. Un fondateur qui ne faisait confiance à personne d'autre pour lire un contrat.

Les anciens contrôles ont pu être utiles. Vérifiez si leur circuit correspond encore au risque et aux personnes autorisées à décider.

Quand les décisions courantes remontent au dirigeant

Le middleware, c'est la chose qui se place entre deux systèmes et traduit de l'un à l'autre. Il est nécessaire quand les systèmes ne peuvent pas se parler directement. Il devient le goulot quand chaque message doit passer par lui, dans l'ordre, avant que quoi que ce soit d'autre arrive.

Un circuit peut faire remonter achats, clients et recrutements vers une même personne alors que d’autres ont l’expertise nécessaire. Avant de le modifier, distinguez les décisions de direction de celles qui attendent une limite jamais définie.

Le motif se manifeste d'abord en petit. L'email où vous êtes en copie sans que ce soit nécessaire. La réunion où rien ne se décide parce que la bonne personne n'était pas dans la pièce et que vous y étiez. Le fil Slack qui attend quatre jours votre feu vert sur quelque chose qui, si c'était une mauvaise idée, coûterait à l'entreprise moins que le temps que vous passez à le lire.

Puis il se manifeste avec du vrai argent. Le client qui a attendu trois semaines une exception tarifaire et est parti chez un concurrent qui a répondu en deux jours. La recrue qui a accepté une autre offre parce que votre circuit de validation du package a duré plus longtemps que tout le cycle d'entretiens de l'autre entreprise. Le contrat fournisseur expiré parce que personne n'a pu faire signer les conditions de renouvellement avant l'échéance.

Rien de tout ça n'est un échec de stratégie. Ce sont des échecs de routage. La décision était évidente. La chaîne, non.

Il y a une raison à tout ça, et l'incompétence n'y est pour rien. Le motif était un comportement rationnel à un moment précis de l'histoire de l'entreprise.

Quand l'entreprise était petite, le fondateur devait tout approuver. C'était ça, le contrôle. C'est comme ça que la qualité restait haute et que l'argent ne disparaissait pas. L'entreprise a grandi. Le fondateur est resté dans la boucle de validation parce que ça avait marché. Personne n'a construit de structure différente. Le système informel a tenu l'échelle tant que le fondateur pouvait encore lire chaque email.

À un moment, le volume a dépassé ce qu'une personne peut traiter sans devenir le délai. Ce moment est différent pour chaque dirigeant. Pour certains, c'était cinquante personnes. Pour d'autres, cent vingt. Pour d'autres, le premier client qui a posé une question à laquelle le fondateur ne pouvait pas répondre de mémoire.

La réponse rationnelle, c'est de déléguer. La réponse structurelle, c'est de construire les conditions où la délégation est sûre.

La plupart des entreprises font la première sans la seconde. Elles donnent aux gens des titres et des responsabilités. Elles ne leur donnent pas de limites de décision. Résultat : la personne à qui on a délégué escalade quand même, parce qu'escalader est plus sûr qu'un mauvais arbitrage. Le PDG est toujours dans la boucle. Le middleware tourne toujours.

Vérifiez les conditions d’une décision bloquée : la personne autorisée à trancher, les informations dont elle dispose et la conséquence du retard. Un titre sans délégation exploitable laisse l’escalade intacte.

Ce dernier point est le tueur silencieux. Une décision lente n'a pas de nom. Elle n'apparaît dans aucun rapport. Elle se manifeste comme le trimestre qui a semblé plat, comme l'équipe qui a arrêté de proposer, comme les clients qui se sont éloignés sans moment dramatique.

Examinez les décisions erronées autant que les décisions tardives. Accélérer le circuit n’est utile que si le responsable dispose des éléments et de l’autorité pour bien décider.

La vitesse seule est un mauvais objectif. Un achat réversible et un engagement critique pour la sécurité demandent des contrôles différents. Mesurez le délai avec le risque et la qualité de décision.

Examiner les cinq dernières décisions

Prenez les cinq dernières décisions passées par vous. Pour chacune, demandez : si cette décision avait été prise par quelqu'un d'autre, au bon niveau, avec l'information dont il disposait, quel est le pire qui aurait pu arriver ?

Si la réponse pour la plupart est une erreur gérable, un résultat retardé ou un apprentissage, alors le problème est le routage lui-même. La qualité de décision allait bien. La personne aurait géré.

Si la réponse est un risque réellement existentiel, alors ces décisions précises appartiennent bien au sommet. La question devient de savoir si vous distinguez les vraies de celles que vous avez été entraîné à traiter comme vraies à cause d'un événement d'il y a des années, dans une entreprise plus petite.

Utilisez les réponses pour distinguer les décisions de direction des validations courantes dont l’autorité et les justificatifs peuvent être définis ailleurs.

La solution n'est pas d'approuver plus vite. C'est d'arrêter de router par vous en premier lieu.

Ça exige de nommer ce qu'est une limite de décision. Un achat sous un certain montant, dans une catégorie fournisseur connue, approuvé par le responsable des opérations, n'a pas besoin de vous. Une exception client qui s'écarte des conditions standard de moins d'un seuil défini, marge protégée, va au directeur commercial. Une embauche sur un poste défini, avec un salaire dans la bande approuvée, se signe par le manager et les RH.

Consignez le seuil, les justificatifs, le valideur et le traitement des exceptions pour chaque décision. Réexaminez cette limite après un incident ou un changement significatif.

Les entreprises qui résolvent ça ne le font pas en faisant davantage confiance. Elles le font en concevant des systèmes où la décision n'a pas besoin de voyager. L'information est assemblée en périphérie. La limite est explicite. Le chemin d'exception est connu. Le PDG voit le motif, pas le paquet.

Être le middleware a un coût qu'on calcule rarement.

Chaque heure passée à router des décisions est une heure où vous ne faites pas le travail que vous seul pouvez faire. La stratégie. La relation qui retient un compte clé. Le recrutement du prochain leader. La direction produit qui détermine si l'entreprise compte encore dans trois ans.

Relevez le temps de direction absorbé et les décisions retardées. L’arbitrage devient visible sans inventer un taux horaire pour le dirigeant.

L'équipe de l'autre côté de vos validations paie aussi. Elle apprend que proposer prend des semaines. Que le jeu sûr, c'est d'attendre. Que celui qui escalade obtient des réponses et que celui qui décide se fait auditer. Avec le temps, l'équipe s'optimise pour ne pas déclencher la file. L'initiative baisse. L'entreprise ralentit. Et le middleware est de plus en plus occupé.

C'est une boucle. La seule sortie de la boucle, c'est de construire la structure qui rend le routage inutile.

Commencez par vérifier si la file de validations crée un problème significatif dans votre activité. Cartographiez les décisions réelles et comparez l’attente aux contrôles nécessaires.

Dans le travail de diagnostic, l'une des premières choses cartographiées est le flux de décision. Pas l'organigramme. Les chemins réels qu'une décision emprunte du déclencheur au résultat. Les passages de relais. L'attente. L'information perdue entre les couches. Les endroits où la même décision est revue deux fois par des gens qui ne savent pas qu'ils revoient la même chose.

Pour chaque passage de relais, demandez pourquoi il existe. Conservez les contrôles juridiques, financiers et opérationnels nécessaires. Vérifiez si les doublons historiques ou les limites de décision absentes expliquent le reste.

Solve IT oriente chaque cas qualifié avant de prescrire une mission. Un problème diffus et transverse peut demander un War Map. Un processus déjà défini peut aller directement vers un Feasibility Sprint borné. Le périmètre, le calendrier, le prix et les contrôles de risque se conviennent pour le cas réel avant le début du travail.

La carte est le point de départ. Pas la solution. La solution vient après que l'entreprise a vu, en termes précis, où voyagent ses décisions et pourquoi.

Vous n'avez pas construit votre entreprise pour être son bus de messages. Vous l'avez construite pour fabriquer quelque chose, servir quelqu'un, et grandir dans une direction que vous avez choisie.

Le motif du middleware est un effet secondaire du succès. L'entreprise est devenue assez grande pour qu'une personne ne puisse plus tenir tous les fils, mais la structure qui permettrait aux fils de tourner sans cette personne n'a jamais été construite.

Les entreprises qui arrêtent de traiter le PDG comme du middleware ne deviennent pas imprudentes. Elles deviennent lisibles. Les décisions avancent. L'équipe apprend à quoi ressemble le bien. Le fondateur récupère son temps, pas parce qu'il a délégué davantage, mais parce que le problème de routage a été résolu au niveau de la structure au lieu du niveau de la boîte mail.