Field Notes_004_Gestion pragmatique des risques pour PME : trois techniques, une architecture, et l'IA qui la rend enfin abordable

À retenir - La plupart des registres de risques de PME ne protègent rien parce qu'ils sont conçus comme des artefacts de conformité, pas comme des instruments de décision. La vraie protection vient de trois techniques nommées exécutées en trois sessions par an - un pre-mortem, une matrice de décision, un exercice trimestriel - et d'un CEO qui traite le risque comme un problème de décision plutôt que comme un problème de documentation. Les outils d'IA comme Claude transforment ce qui était un projet de consultance à 30–50 k€ en une après-midi de travail. L'architecture reste celle de l'opérateur ; le levier est enfin à portée de main.

La gestion des risques dans la plupart des PME, c'est une colonne Excel que personne ne lit. Un heatmap. Un classeur pour le réviseur. Un registre auquel aucun opérateur n'a jamais touché.

Et puis l'entrepôt est inondé. Un fournisseur clé ne répond plus. Un chef de ligne part à la retraite et vingt-deux ans de savoir-faire franchissent la porte avec lui. Dans chacun de ces cas, le registre des risques contenait la bonne ligne. Ce qu'il ne contenait pas, c'était une décision.

Ceci est la quatrième livraison de la série Field Notes. La précédente examinait la résilience de la supply chain au niveau stratégique - le périmètre de l'entreprise. Celle-ci entre dans le bâtiment. Elle s'adresse au CEO qui sait déjà que le récit de la supply chain est partiellement cassé, et qui veut maintenant savoir quoi faire du reste de la surface de risque opérationnelle - les personnes, les permis, les machines, les clients, les systèmes - sans recruter un Chief Risk Officer dont l'entreprise n'a pas besoin.

Le public est le même que dans les trois textes précédents. Fondateurs, dirigeants-propriétaires, CEO, chefs de division, administrateurs actifs. Des gens dont la semaine est jugée sur ce que l'entreprise a réellement fait avancer, pas sur ce qui a été ajouté à un registre.

Pourquoi la plupart des registres de risques en PME ne protègent rien

Toutes les entreprises mid-market dans lesquelles j'ai travaillé ont un dossier de risques. Il vit à la finance. Il est mis à jour une fois par an, la semaine avant l'arrivée du réviseur. Il contient trente lignes, un code couleur en feux tricolores, et une colonne de mitigation rédigée au conditionnel. Il est ouvert en février, puis en septembre, et à aucun autre moment de l'année.

Le document réussit exactement une chose. Il permet au conseil d'administration d'enregistrer que le sujet a été « considéré ». Il ne produit pas une entreprise plus difficile à briser.

La raison n'est ni l'effort ni l'intelligence. La raison est le design. Un registre des risques, tel que pratiqué dans la plupart des PME, est un artefact de conformité - un document construit pour démontrer à un observateur externe que le sujet a été abordé. Une architecture des risques est un instrument de décision - un système construit pour modifier ce que l'entreprise fait réellement quand un signal défini arrive. Les deux se ressemblent superficiellement sur le papier. Ils se comportent de manière totalement différente en situation de crise.

Un risque qui n'est pas chiffré n'est pas géré. Un risque qui n'est pas associé à une action pré-décidée n'est même pas un risque : c'est de l'angoisse en format PowerPoint. Et une entreprise qui confond l'artefact avec l'instrument s'est construit un placebo - un objet qui produit le sentiment de la gestion des risques sans produire le comportement de la gestion des risques.

Le problème en PME est plus aigu qu'en société cotée. Une société cotée peut s'offrir un Head of Risk, une deuxième ligne de défense, un audit interne et l'appareillage qui les entoure. Une PME de 5 à 50 M€ de chiffre d'affaires ne le peut pas. Le manuel ERM standard, appliqué à l'échelle PME, produit soit un document non lu, soit une fonction à temps partiel pour le directeur financier qui en vient à détester ce travail. Aucune des deux issues ne protège l'entreprise.

L'architecture ci-dessous est conçue pour cette contrainte. Trois techniques nommées. Trois sessions par an. Pilotée par l'opérateur. Pas de deuxième ligne, pas d'équipe de consultance, pas de mission de 40 k€ pour entretenir le cadre. Conçue pour survivre à la bande passante qu'un CEO de PME a réellement.

Le risque est un problème de décision

Retirez l'appareillage, et le principe opérationnel tient en une ligne : la gestion des risques dans une PME physique ne consiste pas à documenter le risque ; elle consiste à pré-décider ce qui se passe quand un signal défini arrive.

Le signal, c'est le volume au mauvais endroit - le fournisseur qui ne répond pas avant mardi, le stock sous le seuil de déclenchement, la démission qui révèle un single point of failure, l'alerte cyber qui franchit un seuil défini. La décision, c'est l'action nommée - le second fournisseur appelé, la ligne de production arrêtée, le programme de cross-training accéléré, l'équipe d'intervention convoquée. L'architecture, c'est la relation entre les deux - pré-décidée, écrite, attribuée à un nom, suffisamment répétée pour que le muscle tienne sous la pression.

Ce que les documents ne produisent pas, et que les architectures produisent, c'est la vitesse de décision sous stress. Un registre de risques ouvert lors du conseil d'administration ne peut pas déplacer une commande fournisseur. Une règle de décision, intégrée dans le dossier des opérations, avec un propriétaire nommé et un chemin d'escalade testé, oui. L'écart de performance entre les deux, dans un vrai choc, n'est pas de 20 %. C'est la différence entre perdre un trimestre et perdre l'entreprise.

Les entreprises qui traversent les cycles ne sont pas celles qui ont des tableaux plus élégants. Ce sont celles qui savaient déjà qui décide - avant que le téléphone sonne.

La méthode : trois techniques, trois sessions, une architecture

Ce qui suit est l'expression opérationnelle du principe, distillée à partir de recherches sur la manière dont les scale-ups performantes et les équipes SRE pilotent leur résilience opérationnelle, et à partir de dix-huit mois sur le siège d'opérateur d'une entreprise industrielle belge. Aucune des trois techniques n'est inventée. Chacune est empruntée à une discipline qui l'a testée dans des conditions beaucoup plus dures que celles d'une PME.

01 - Le pre-mortem

La première session est le pre-mortem. La technique a été formalisée par Gary Klein dans un article de la Harvard Business Review en 2007, construit sur des recherches antérieures de Mitchell, Russo et Pennington (1989) montrant que la hindsight prospective - s'imaginer qu'un résultat a déjà eu lieu - améliore d'environ trente pour cent l'identification correcte des causes d'échec.

La session dure deux heures. L'équipe de direction est dans une pièce. Le CEO pose le cadre en une phrase : « Nous sommes dans dix-huit mois. L'entreprise vient de perdre 500 k€ à cause d'une seule défaillance. Que s'est-il passé ? » L'équipe écrit ensuite - individuellement, sur papier, pendant quinze minutes - toutes les causes plausibles qui lui viennent à l'esprit. Les réponses ne montent au mur qu'après cette phase d'écriture.

La discipline fait la différence. Demander « qu'est-ce qui pourrait mal tourner » produit une liste polie. Demander « qu'est-ce qui a déjà mal tourné, dans le monde que nous imaginons » produit une liste candide. La différence tient à la permission psychologique que la hindsight prospective donne à la salle - celle de nommer le fournisseur que le CEO protégeait, le manager qui est le single point of failure, le raccourci de maintenance dont tout le monde fait semblant qu'il est acceptable.

Le livrable de la session est un diagramme en nœud papillon (bow-tie) des trois principales modes de défaillance. Le bow-tie est la norme en sécurité des procédés industriels - menaces à gauche, événement central au milieu, conséquences à droite, avec des barrières préventives et atténuantes nommées de chaque côté. Il est plus utile qu'une heatmap parce qu'il montre, pour chaque mode de défaillance, ce qui l'arrête actuellement et ce qui l'absorbe actuellement - et donc où l'entreprise a des barrières minces ou absentes. Une heatmap vous dit qu'il y a un problème. Un bow-tie vous dit quelle barrière construire.

02 - La matrice de décision

La deuxième session est la matrice de décision. Elle prend les principales modes de défaillance issus du pre-mortem et convertit chacun en protocole pré-décidé.

La structure emprunte à RAPID (le cadre Bain : Recommend, Agree, Perform, Input, Decide) ou à RACI-VS, selon l'exposition antérieure de l'entreprise. La granularité qui compte à l'échelle PME, ce n'est pas l'étiquette du cadre ; ce sont les quatre questions auxquelles on répond pour chaque mode de défaillance majeur : Qui décide ? Quel seuil déclenche la décision ? Quelle est la fenêtre de réponse ? Qui exécute ?

La matrice tient sur une page. Elle vit là où le travail se fait - les opérations, pas la finance. Elle nomme des personnes, pas des départements. Elle définit numériquement les déclencheurs partout où un chiffre est honnête - « stock inférieur à 14 jours de couverture pour le groupe SKU A », et non « stock bas ». Et elle précise une fenêtre de réponse en heures, et non en « dès que possible ».

La raison pour laquelle la matrice est le cœur opérationnel de l'architecture, c'est qu'elle convertit un registre des risques d'un document en un comportement. Un registre des risques dit au CEO qu'une défaillance fournisseur serait matérielle. Une matrice de décision dit au responsable des opérations que, si le fournisseur X ne répond pas avant la fermeture mardi, il ou elle a l'autorité de placer une commande de secours chez le fournisseur Y avant la fermeture mercredi - sans escalade vers le CEO, sans attendre une réunion, sans la perte de quarante-huit heures qui transforme presque toujours une perturbation gérable en perturbation ingérable.

Un registre documente le risque. Une matrice de décision décide de ce qui se passe ensuite.

03 - L'exercice trimestriel

La troisième session est l'exercice. C'est la seule qui se répète.

L'exercice est emprunté à la pratique du chaos engineering et du Site Reliability Engineering qu'utilisent des entreprises comme Shopify, Stripe et AWS pour garder leur résilience opérationnelle honnête. Dans sa forme logicielle complète - un « game day » - l'équipe d'ingénierie injecte volontairement une panne dans le système de production et observe comment la réponse humaine et machine se comporte réellement. Ce que ces équipes découvrent généralement : le runbook est faux, les dashboards mentent, et la personne nominalement de garde est en vacances.

Mis à l'échelle PME, l'exercice dure deux heures par trimestre. Un scénario à la fois, tiré du bow-tie. De vrais appels téléphoniques. Le CEO ou le COO joue l'arbitre du scénario. Les propriétaires nommés dans la matrice de décision exécutent réellement leur rôle - appeler le fournisseur de secours, descendre sur le terrain, émettre l'ordre d'arrêt. La session se termine par un rétrospectif au cours duquel deux questions reçoivent une réponse honnête : qu'est-ce que la matrice avait faux, et qu'est-ce qui doit changer ?

L'exercice est la discipline qui maintient l'architecture en vie. Un pre-mortem réalisé une fois est intéressant. Un pre-mortem réalisé une fois et jamais testé est oublié dès la deuxième année. Une matrice de décision qui n'a jamais servi dans un exercice est un document. Une matrice de décision utilisée dans quatre exercices par an pendant deux ans est de la mémoire musculaire - et la mémoire musculaire est ce qui produit le bon comportement sous stress, au moment où la partie analytique du cerveau a déjà quitté le bâtiment.

Le levier IA : ce qui change quand une PME a Claude

Pendant les vingt dernières années, l'architecture à trois techniques ci-dessus était, en principe, disponible pour toute entreprise. En pratique, elle était disponible pour les grandes entreprises. La raison était le coût. Un pre-mortem facilité, un atelier bow-tie, la construction d'une matrice de décision, et quatre exercices trimestriels coûtaient à une entreprise mid-market entre 30 000 et 60 000 € par an de frais de consultance externe - une fois le temps du consultant, le matériel, le reporting et le suivi honnêtement chiffrés.

Cette contrainte économique s'effondre. Un outil d'IA généraliste comme Claude ne rend pas plus faciles les parties d'oeuvre de jugement opérateur dans la gestion des risques - et comme je le dirai dans la section suivante, c'est le bon résultat. Ce qu'il fait, c'est faire s'effondrer le coût de chaque partie autour du jugement opérateur : structurer, rédiger, faciliter, simuler, documenter, traduire.

Ce que Claude fait réellement, dans cette architecture :

Il facilite le pre-mortem. Le CEO et l'équipe de direction briefent Claude sur l'entreprise, l'environnement opérationnel et les modes de défaillance évidents. Claude exécute alors un prompt de pre-mortem structuré - il pose le cadre « Nous sommes dans dix-huit mois… », demande à chaque membre d'énumérer les causes, regroupe les réponses, fait remonter les modes de défaillance sous-discutés que l'équipe a évité de nommer. La session se passe toujours dans la pièce ; la facilitation qui demandait auparavant un consultant externe passe désormais par l'IA.

Il rédige le bow-tie. Étant donné un événement central et une description des opérations, Claude peut produire en quelques minutes une première version d'un diagramme bow-tie - menaces, barrières, facteurs d'escalade, conséquences - que l'équipe de direction corrige plutôt que construit à partir de zéro. La correction est le travail de l'opérateur, et elle est plus rapide que la construction. L'équipe boucle un bow-tie en une après-midi là où il fallait auparavant une semaine d'atelier.

Il construit la matrice de décision. Étant donné le bow-tie et l'organigramme de l'entreprise, Claude rédige une matrice de décision candidate - propriétaires nommés, seuils candidats, fenêtres de réponse candidates. L'équipe de direction conteste chaque ligne. La version contestée, celle qui est finalement adoptée, est bien meilleure que ce qui aurait été produit à partir d'une page blanche un mardi après-midi.

Il joue l'adversaire de table lors de l'exercice. Le CEO n'a plus à concevoir le scénario ni à jouer les deux côtés. Claude prend le rôle du fournisseur défaillant, de la menace cyber, du régulateur, du journaliste - alimente l'équipe en temps réel avec des prompts réalistes et croissants, enregistre les réponses, signale les moments où la matrice de décision n'a pas fourni de réponse claire. Le rétrospectif s'écrit tout seul à partir du journal de session.

Il maintient les artefacts entre les sessions. Le bow-tie, la matrice, le journal d'exercice, le rétrospectif - tous sont mis à jour par l'IA à mesure que l'entreprise évolue. Le CEO révise les mises à jour plutôt que de les produire.

Ce qui change économiquement, c'est la structure de coût de l'exécution de l'architecture. Le travail qui résidait auparavant chez un consultant externe - facilitation, documentation, conception de scénarios, suivi - réside maintenant dans un outil d'IA qui coûte moins par an qu'une journée de consultance. Le travail qui reste chez l'opérateur, c'est le jugement : quels risques comptent, qui décide, quel seuil est le bon, quand outrepasser la matrice. Ce travail est la partie qui n'aurait jamais dû être externalisée. C'est aussi la seule partie qui compose dans le temps.

Ce que l'IA ne change pas

Le CEO ne délègue pas l'architecture au modèle. Le modèle rédige. Le CEO décide. Cette distinction est la phrase la plus importante de ce texte.

Une matrice de décision rédigée par Claude et jamais contestée par l'équipe de direction est un document moins bon que celui que l'entreprise aurait écrit elle-même. Il est plausible, bien structuré, complet - et déconnecté de la réalité opérationnelle que seul l'opérateur peut voir. Claude ne sait pas que le responsable de la maintenance est le seul à pouvoir réellement démarrer la ligne de secours. Claude ne sait pas que le fournisseur X est aussi le beau-frère du directeur des achats. Claude ne sait pas quel seuil le syndicat traitera comme une provocation. L'opérateur, lui, le sait. L'architecture ne fonctionne que lorsque le jugement de l'opérateur est l'entrée contraignante.

C'est le même principe que la deuxième Field Note appliquait à la fixation des priorités. Les cadres ne sont pas la source du focus ; ils en sont l'expression. L'architecture n'est pas la source de la résilience ; elle en est l'expression. La source, c'est la discipline de décision du CEO. L'IA modifie le coût d'exécution de la discipline. Elle ne la remplace pas.

La discipline plus difficile

Un registre des risques dit au réviseur que le sujet a été considéré. Une architecture de décision dit à l'entreprise quoi faire le jour où l'entrepôt est inondé. Les deux résultats se ressemblent sur le papier. Ils produisent des effets opposés en situation de crise.

Ce que l'architecture ci-dessus ne promet pas, c'est que rien n'ira mal. Beaucoup de choses iront mal. Le prochain choc supply chain, le prochain incident cyber, le prochain événement key-person, la prochaine inflexion réglementaire - ils arrivent, à un rythme que la classe opérateur ne peut pas prédire et qu'elle devrait cesser d'essayer de prédire. Ce que l'architecture promet, c'est que lorsque chacun arrive, l'entreprise a déjà décidé ce qu'elle fait. La décision est dans la matrice. Le propriétaire est nommé. La fenêtre de réponse est définie. L'équipe l'a répétée.

Les cadres existaient déjà. Le levier pour les faire tourner à l'échelle PME n'existait pas. Il existe maintenant. Les entreprises qui paraîtront déraisonnablement résilientes en 2030 seront celles dont les CEO mettent en place l'architecture en 2026 - trois sessions, trois techniques, un instrument de décision, et une IA qui rend enfin l'économie possible.

La prochaine Field Note revient à l'intérieur de l'entreprise : comment le CEO utilise la même architecture à trois techniques pour gérer spécifiquement le risque personnes - le single point of failure auquel presque toutes les PME belges sont structurellement exposées, et auquel presque aucune n'a mis de prix.

Ruben Claessens est CEO d'un groupe industriel en Belgique et fondateur de LIDI Partners BV. Field Notes est l'archive publique de son travail sur l'opératorat, la gouvernance et la réalité belge du mid-market. Publié délibérément, à un rythme mensuel.

- Bruxelles, mai 2026