« Ivre, positif à la cocaïne et au cannabis, conducteur sans assurance : il endommage des infrastructures et cause des millions d'euros de dégâts ». L'affaire de l'accident du RER C a fait pendant plusieurs jours la Une des tous les médias grand public. Tout ça pour nous expliquer qu'un type tout seul peut créer des dommages sévères et des pertes financières tout aussi sévères. Bon, d'accord... C'est bien regrettable. Mais le type en question n'est qu'un petit joueur ! Imaginons ce qu'un DSI, ivre, positif à la cocaïne et au cannabis pourrait causer comme dégâts !

La facture pourrait atteindre facilement quelques centaines de millions d'euros. Voire même des milliards pour un DSI d'une entreprise multinationale. Il suffit, accidentellement bien sûr, de bousiller quelques mainframes, de saboter quelques serveurs DNS ou de couper toutes les messageries. Un sacré bazar en perspective ! On imagine les titres des journaux : « Un DSI ivre et drogué perd le contrôle de son véhicule immatériel à cause d'un verglas bogué persistant et endommage les infrastructures. » Il va peut-être falloir que j'interdise définitivement les pots à la DSI... On ne sait jamais.

Dans mes louables efforts d'optimisation de nos méthodes de travail, j'ai systématisé un partage des responsabilités parmi mes équipes et dans leurs relations avec les directions métiers. Je me suis inspiré de l'approche que l'on trouve dans les référentiels, en particulier Itil. En clair, l'approche RACI qui différencie ceux qui Réalisent, qui Approuvent, qui sont Consultés et qui sont Informés. Il est vrai que cela devenait un peu le bazar dans notre gestion de projet, entre ceux qui réalisent sans approbation (si, si, ça existe, ça leur fait tellement plaisir...), ceux qui approuvent des tâches auxquelles ils ne comprennent rien, ceux qui veulent être consultés sur tout simplement pour le plaisir d'être en réunion parce qu'ils n'ont pas d'autre chose à faire, et ceux que l'on informe mais qui en profitent pour remettre en cause ce que d'autres ont approuvé sans le réaliser mais en étant consultés.

Lire la suite dans le numéro 34 de la revue Best Practices Systèmes d'Information.