Au-delà des flowcharts : le travail invisible de la gouvernance

La plupart des gens se représentent la gouvernance comme un ensemble d’artefacts : un flowchart, un cadre, un mécanisme de vote. Ils comptent, mais c’est la partie facile. Ce qui décide si un système fonctionne vraiment, c’est tout ce qui se passe une fois le schéma dessiné, dans le quotidien sans éclat que presque personne ne voit.

Il y a un large écart entre la gouvernance sur le papier et la gouvernance en pratique. Un cadre peut être élégant et ne rien produire, parce qu’il ne décrit au fond que la façon dont les décisions sont censées circuler. Il dit peu de choses sur qui relance une décision une fois prise, qui remarque quand quelque chose cale, ou qui tient les registres à jour six mois plus tard. Ce travail est en grande partie invisible, et c’est là que les systèmes cassent sans bruit. Combler cet écart est toute la raison d’être de GovOps, et c’est le sujet de ce texte.

La gouvernance, c’est plus qu’un cadre

Un cadre n’est jamais qu’un point de départ. La raison la plus fréquente de l’échec d’une gouvernance, c’est qu’on la traite comme quelque chose que l’on construit une fois puis que l’on laisse de côté. Le flowchart est affiché, tout le monde s’accorde à dire qu’il a l’air juste, et l’on suppose que le système va désormais fonctionner tout seul. Ce ne sera pas le cas.

Une gouvernance ne produit des résultats que si quelqu’un porte le suivi opérationnel : l’aiguillage, les relances, l’enregistrement, tout ce travail qui transforme une décision en action, avec un nom et une date. C’est là qu’intervient GovOps.

GovOps traite la gouvernance et les opérations comme une seule discipline, et non comme deux.

Le versant conception, ce sont l’architecture, les rôles, les droits de décision et l’obligation de rendre des comptes. Le versant opérations, c’est tout ce qui fait que cette architecture continue de fonctionner une fois que de vraies personnes s’en servent. La plupart des cabinets livrent la conception et passent à autre chose. GovOps la mène jusqu’au point où le système fonctionne vraiment.

Le travail invisible qui fait fonctionner la gouvernance

Quand un système de gouvernance fonctionne, c’est en général grâce à une poignée de choses que personne ne met sur une diapositive. Les décisions sont documentées de façon à pouvoir être retrouvées plus tard, parce qu’une décision que personne ne retrouve finit toujours par être rejouée. Les délais et les personnes sont suivis, pour que ce qui a été convenu continue d’avancer une fois la réunion terminée. Les engagements sont relancés, et les petits manquements sont repérés avant de devenir une habitude. Et quand les gens ne sont pas d’accord, ce qui arrivera, quelqu’un fait le travail ordinaire de les ramener dans le cadre.

J’ai vu à quel point cela compte chez Allianz. La structure formelle n’a jamais été toute l’histoire. Ce qui faisait avancer les choses, c’était le travail fait autour : le point improvisé pour débloquer un sujet, l’alignement rapide par message, quelqu’un qui réorganise sa propre journée pour couvrir l’urgence d’un collègue, la communication régulière qui gardait tout le monde orienté dans la même direction. Rien de tout cela n’était documenté, rien n’apparaissait dans aucun cadre, et personne n’en recevait le mérite. Mais c’était réel, et c’était la raison pour laquelle le système produisait des résultats.

Voici la partie que la plupart des gens ratent, je crois. Ce travail invisible portait l’organisation, mais il la portait à force de bras. Il fallait beaucoup de monde passant beaucoup d’heures à combler des trous à la main. Quand la gouvernance et les opérations sont conçues ensemble, correctement, on obtient la même fiabilité avec beaucoup moins de cet effort caché : moins de monde, moins d’héroïsme, un système tout simplement moins coûteux à tenir. C’est le vrai gain, et il est rare, parce que presque personne n’investit dans la moitié qu’il ne voit pas.

The Sandbox DAO est l’endroit où nous avons pu construire pour cela dès le départ. Nous avons piloté sa gouvernance pendant trois ans, avec un budget de fonctionnement de 7,5 millions de dollars sur deux ans, et le cadre s’est révélé être la petite partie. Le vrai travail était opérationnel. Nous avons standardisé l’arrivée des propositions, puis allégé l’examen et la vraie mise à l’épreuve qui suivait, les allers-retours avec chaque auteur pour vérifier ce qu’il demandait réellement. Une fois une proposition adoptée, nous assurions le suivi des jalons et le contrôle qualité pour tenir l’auteur à ses engagements, adossés à une gestion de trésorerie volontairement simple. Et nous bouclions la boucle en rendant compte à la communauté de façon semi-automatisée, pour que la transparence ne dépende jamais de quelqu’un qui trouve le temps. À deux seulement pour tout examiner, le système devait être efficace plutôt que laborieux.

Pourquoi le travail invisible passe inaperçu

Le travail invisible passe facilement inaperçu, pour deux raisons. La première est évidente : il n’y a rien à regarder. Un nouveau cadre, on peut le montrer. Une transmission propre entre une décision et son exécution, on ne la remarque que lorsqu’elle échoue.

La seconde est plus subtile, et d’après mon expérience c’est elle qui fait le vrai dégât. Les organisations supposent que nommer les rôles revient à couvrir le travail. Le responsable de bout en bout d’un projet est en général un rôle défini, standardisé. Il figure bien sur l’organigramme. Ce qui lui manque souvent, c’est une autorité réelle. Si bien que l’avancée d’un projet dépend de la personne qui occupe le poste : les opérateurs solides le font passer à force de crédibilité personnelle et de volonté, et là où cet élan manque, il cale sans bruit. La case sur l’organigramme a l’air remplie dans les deux cas, et c’est exactement pour cela que la dépendance reste cachée.

C’est donc moins un problème de processus qu’un problème de leadership. Nommer un responsable est facile, et la plupart des organisations le font déjà. Lui donner les moyens d’agir, l’autorité pour faire avancer un projet à travers les équipes et les entités, c’est la partie que l’on saute. Un système qui ne fonctionne que si la bonne personne se trouve au bon poste n’est pas vraiment un système. C’est une série de coups de chance.

Construire une gouvernance qui fonctionne en pratique

La solution est de concevoir pour le quotidien dès le départ, plutôt que de l’ajouter une fois que les choses cassent déjà. Et il faut la concevoir avec les personnes qui la feront vivre, pas depuis une tour d’ivoire. Un processus qui a l’air propre sur un schéma mais ignore la façon dont le travail se fait vraiment sera contourné en silence en moins d’un mois.

En pratique, cela veut dire intégrer les processus opérationnels à la conception elle-même, donner au responsable de bout en bout une véritable autorité, et suivre quelques indicateurs honnêtes sur la santé du système, comme le temps qu’il faut à une décision pour passer de soulevée à tranchée, ou la part des décisions qui atteignent réellement l’exécution.

Mais le signal le plus fiable que j’aie trouvé n’est pas un indicateur. C’est de savoir si le système aide votre équipe ou la fait souffrir. Si vos équipes portent le processus à bout de bras en silence, le contournent, le redoutent, c’est le signe que la gouvernance est devenue un fardeau plutôt qu’une colonne vertébrale. Bien conçu, GovOps doit alléger les personnes qui le vivent, pas les alourdir. Au moment où il commence à leur coûter, quelque chose ne va pas dans la conception.

Ce que nous avons appris chez Arasakio

Une leçon se détache de toutes les autres. Décentralisation et clarté opérationnelle ne s’opposent pas, même si on les traite souvent comme si c’était le cas. On peut distribuer largement la prise de décision et rester précis sur qui porte quoi une fois un choix fait, et les systèmes qui durent savent en général faire les deux à la fois. Des opérations proactives battent aussi toujours des opérations réactives, parce que repérer tôt une décision bloquée ne coûte presque rien à côté du désalignement qu’il faudra démêler un mois plus tard.

Cela n’a pas non plus besoin de s’éterniser. Concevoir un dispositif GovOps complet, de bout en bout, est un sprint ciblé de six à douze semaines, pas un coût permanent. Le but est de laisser derrière soi un système qui fonctionne seul, pas d’installer un processus qu’il faut sans cesse alimenter.

En bref

J’ai appris tout cela à mes dépens. Chez HSBC et Allianz, j’ai essayé de revoir de l’intérieur la façon dont les choses fonctionnaient, et ça n’a pas pris, parce que j’avais sous-estimé le travail invisible que mes collègues faisaient en silence pour tenir l’existant. Nous avons changé les cases et les flèches en supposant que le reste suivrait. Il n’a pas suivi. C’est de cet échec qu’est née l’approche GovOps. Je suis convaincu que la conception de la gouvernance et les opérations sont un seul et même métier, et que la partie que personne ne voit est en général celle qui décide si ça marche.

La gouvernance n’a donc jamais vraiment été une affaire de flowchart. C’est le travail continu et invisible qui transforme le flowchart en résultats.

La question à poser sur n’importe quel système n’est pas de savoir si le cadre est bon, mais si quelqu’un le pilote vraiment.

Chez Arasakio, nous faisons du GovOps : la conception de la gouvernance et les opérations ensemble, construites pour que le système fonctionne en pratique plutôt que sur le papier. Que vous partiez de zéro, que vous changiez d’échelle ou que vous traversiez une transition, nous apportons la structure, l’obligation de rendre des comptes et le leadership opérationnel pour que ça tienne.