Dégrader son processus : le piège cognitif

Récemment je suis tombé sur la chaîne Sénat sur l’audition d’une journaliste qui (lors d’une enquête sous anonymat) s’est faite recrutée dans le secteur de la petite enfance. Elle explique que cela a duré 8mn chrono et sans aucune vérification de ses antécédents judiciaires, le recruteur arguant qu’en principe il faut vérifier le casier judiciaire, mais que là il y avait trop de besoin, le temps lui manquait.

(ce filet a pour sujet l’analyse processus, et pas les affaires qui ont secoué ce secteur depuis le début 2026).

Ce dysfonctionnement est un cas d’école de ce qui se passe à peu près partout dans l’IT en général, et dans la cyber en particulier, et il mérite que l’on s’y penche pour en décortiquer le dysfonctionnement, et surtout analyser la root cause. Ou plutôt les root cause successives, car il y en a au moins 2.

Première root cause : vu du recruteur l’équation est simple : il y a un flux important de demandes (les recrutements des personnels à envoyer dans les centres de loisirs) et les moyens pour les assurer sont sous-dimensionnés, il faut donc aller au plus vite pour ne pas interrompre le flux, quitte à shunter certaines étapes. Dit autrement, de son point de vue, tout ce qui est sur le chemin critique de la production du bien / service demandé et qui n’est pas strictement nécessaire est susceptible d’être éliminé. Parallèle avec l’IT : un projet mis en production sans homologation ni analyse RGPD parce que « on est tendu côté planning », une mise à jour de version faite un vendredi à l’arrache sous la pression de la MOA.

Or, c’est une très mauvaise idée, et ceci pour au moins 3 raisons. La première, c’est que shunter une obligation réglementaire ou normative engage la responsabilité de l’agent qui prend, de son propre chef, cette décision qui en plus ne relève pas de son périmètre. En cas de gros pépin, faites confiance à toute la chaîne de commandement pour dire « qu’ils ne savaient pas », que l’agent « ne les a pas alerté », qu’à aucun moment « ils n’ont donné de telles consignes », etc.

La deuxième, c’est que si ces procédures ou obligations normatives existent ce n’est pas pour rien. Dans l’aéro on dit que les procédures ont été écrites avec le sang des pilotes décédés, vous voyez l’image. Si on dit que l’on ne met JAMAIS en production un vendredi, c’est qu’il y a une raison – et on continue de voir, en 2026, des petits malins qui se pensent au-dessus des lois de la physique et qui vous expliquent que oui mais non c’est juste une correction mineure, mais t’inquiète, j’ai testé ça va le faire. NON.

La troisième doit être analysée sous l’angle de l’approche processus. Un processus, ça prend des trucs en entrée (les demandes de recrutement, les demandes de mise à jour de version logicielle, etc.), ça produit des trucs en sortie (une personne recrutée, un logiciel mis à jour) le tout avec un certain nombre de paramètres (description des activités, etc.), en particulier les moyens RH et financiers affectés au processus. Or, en acceptant de maintenir le flux des trucs en sortie (le niveau de service) dans un contexte de moyens RH/Fi sous-dimensionnés (qu’il s’agisse du dimensionnement initial ou d’une perte de moyens, genre départ d’agent ou arrêts maladie en série), le processus se retrouve avec un risque implicite ni formalisé, ni remonté à la hiérarchie. Et bien évidemment, toute la cascade des processus internes à l’Organisation va embarquer le même genre de dysfonctionnement, chacun un petit bout de risque non-formalisé (ni remonté) embarqué dans ses activités. De sorte qu’au bout du compte, l’Organisation peut se trouver avec une montagne de micro-risques qui, mis bout à bout, peuvent faire très mal en cas d’incidents.

La seconde root cause est plus « tricky » et on doit pour cela invoquer le concept de modèle mental (MM) : qu’est-ce qui diable peut passer par la tête de quelqu’un qui connaît un risque (envoyer dans un centre aéré une personne au casier judiciaire chargé) de prendre sur elle de shunter ces vérifications, au final à cause de moyens qu’on ne lui a pas donné ? La réponse se trouve dans un fabuleux ouvrage de Philippe d’Iribarne : « La logique de l’honneur ». C’est typique de la culture française est c’est (selon d’Iribarne) issu de l’ancien régime : il est courant qu’un employé d’une Organisation, quel que soit son niveau hiérarchique, se voit investi d’une « mission » qui transcende les fiches de poste, les procédures, les règles. J’ai personnellement été témoin de pratiques d’informaticiens qui shuntent absolument toutes les bonnes pratiques projet au motif qu’« il est de sa mission de rendre un service à ses MOA », de pharmaciens qui dégradent les vérifications de délivrance médicamenteuse au motif qu’« il est de leur mission de ne pas laisser les services en rupture de médicaments » (pour information, les erreurs médicamenteuses dans les établissements de santé, c’est plusieurs milliers de morts par an selon les sources, dont 95 % sont évitable selon la HAS). Aucun de ces exemples ne relèvent de la volonté de nuire, mais d’une absence de vision processus / risque de son activité.

Dernier argument, que je me garde en réserve dans les cas où je tombe sur un boucher bas de plafond : si vous acceptez de rendre le même service avec 2 fois moins d’agents qu’avant, c’est qu’avant la moitié des agents de votre service n’en fichait pas une ramée. En général là ça percute.

cedric@cartau.net