Introduction
Un employé découvre qu'un script de son collègue efface des fichiers au lieu de les déplacer. Il le corrige, intègre des vérifications d'erreur, et évite à toute une équipe de perdre des heures de travail. Résultat : il est convoqué par sa hiérarchie pour avoir « fait le travail de quelqu'un d'autre ». L'histoire se passe dans les années 1980, dans un centre informatique municipal. Ce qui frappe, c'est qu'elle reste parfaitement reconnaissable aujourd'hui.
Le périmètre comme ligne de démarcation
Dans de nombreuses organisations IT, la fiche de poste est devenue une frontière à ne pas franchir. Chaque équipe défend son territoire, et toute intervention en dehors du périmètre assigné — même bien intentionnée — peut déclencher une réaction défensive. La logique paraît cohérente : des responsabilités claires évitent les redondances et les conflits. Mais en pratique, elle génère un paradoxe : les profils les plus engagés, ceux qui voient l'ensemble du système et veulent résoudre les problèmes, deviennent une source de tension plutôt qu'un atout.
Les conséquences sont concrètes. Des incidents qui se situent à la jonction de deux périmètres restent non traités. Personne ne les « possède » officiellement, donc personne n'intervient. Et quand quelqu'un prend l'initiative de le faire, il est rappelé à l'ordre.
Une sélection silencieuse vers le bas
Les profils IT les plus compétents — développeurs, architectes, ingénieurs DevOps — partagent souvent un trait commun : ils n'exécutent pas seulement des tâches, ils observent, anticipent et cherchent à améliorer. Quand une organisation décourage systématiquement cette énergie, elle envoie un message clair : votre initiative n'est pas la bienvenue ici.
Ce sont précisément ces profils qui ont le plus d'options sur le marché. Ils partent. Ils rejoignent des équipes où leur manière de travailler est reconnue — et souvent, c'est la concurrence qui bénéficie directement de leur départ.
Retenir les talents IT est déjà difficile dans un contexte de pénurie structurelle et de forte mobilité. Une culture qui punit l'initiative aggrave ce problème de façon silencieuse, sans qu'aucun indicateur RH ne le capture directement. Le taux de rotation monte, les causes restent floues, et les entretiens de départ produisent des réponses policées qui ne disent pas tout.
Ce que DevOps et SRE ont compris
Il n'est pas anodin que les méthodologies ayant structuré la modernisation des DSI ces quinze dernières années — DevOps, SRE, Platform Engineering — reposent toutes sur un principe commun : les problèmes ne respectent pas les périmètres organisationnels. Un ingénieur qui repère une anomalie en production et la corrige sans attendre que le bon ticket arrive sur la bonne file, ce n'est pas du débordement. C'est exactement ce que la résilience opérationnelle exige.
Les organisations qui réussissent leur transformation numérique ne sont pas celles dont les fiches de poste sont les plus précises. Ce sont celles où les équipes se sentent autorisées à agir — et où le management renforce ce comportement plutôt que de le sanctionner.
Trois leviers pour inverser la dynamique
L'anecdote des années 1980 décrit un monde de mainframes et de traitements batch. Mais le réflexe organisationnel qu'elle illustre reste bien vivant. Quelques actions concrètes permettent de l'inverser :
- Évaluer explicitement l'initiative transversale, pas seulement l'exécution dans le périmètre assigné. Ce qui est mesuré finit par être valorisé.
- Organiser des post-mortems sans recherche de coupable (blameless post-mortem), pour créer un espace où signaler un problème est perçu comme une contribution, non comme un risque.
- Éviter de territorialiser les responsabilités dès qu'un incident est détecté hors périmètre — la première question ne devrait pas être « qui aurait dû le voir ? » mais « comment l'empêcher de se reproduire ? ».
L'objectif n'est pas de supprimer les responsabilités clairement assignées — elles restent indispensables à l'opérationnel. C'est de faire en sorte que lorsqu'un collaborateur repère un problème en dehors de son domaine, son premier réflexe soit de le signaler ou de l'adresser, pas de regarder ailleurs pour éviter les ennuis.