Analyse d’une DSI selon le paradigme de la chaîne alimentaire

Au sommet de la chaîne alimentaire, il y a les ingénieurs système. Ce sont des personnes (hommes ou femmes, mais le plus souvent des hommes) qui maîtrisent les couches basses d’un SI : systèmes d’exploitation, middlewares, bases de données, stockage, sauvegarde, etc. Ils passent souvent pour des semi-magiciens, le genre qu’il ne faut pas chatouiller sous peine de se retrouver changé en clé USB ou en chargeur de Nintendo. Quand j’en étais un, dans un dîner en ville, on m’avait présenté comme tel à un invité : si on lui avait annoncé que j’étais le neveu de Voldemort, il ne m’aurait pas regardé autrement.

Un peu plus bas dans la chaîne (toujours selon cette classification), on trouve les responsables fonctionnels, ceux qui sont capables de parler à la fois un peu technique et un peu métier. Puis, encore plus bas, le gnouf : la hotline et les équipes micro. Je dis le gnouf, parce que, pour ce qui concerne l’équipe micro, pendant des années le niveau technique nécessaire était relativement faible, et parce que, de son côté, la hotline a été pendant des années largement composée de salariés en reclassement pour ne pas dire placardisés (il va falloir que l’on m’explique quel raisonnement tordu peut conduire un décideur à placer dans ce qui représente la vitrine d’une DSI les personnels les moins motivés d’un hôpital, quand même la SNCF a compris qu’il fallait s’y prendre autrement il y a plus de 20 ans).

Mais ça, c’était avant : si votre DSI fonctionne toujours selon ce modèle, c’est que le compteur est resté bloqué au milieu des années 1990. Parce que, clairement, la chaîne alimentaire est en train de s’inverser, et ce pour deux raisons.

La première, c’est que depuis cette époque sont passées par là plusieurs normes, ou méthodes, ou approches, ou comme vous voudrez les nommer, qui inversent les ordres de priorité. La première méthode, dénommée TOC (Theory of Constraints), a été élaborée par Eliyahu M. Goldratt et développée dans son ouvrage majeur, Le But, publié aux éditions Afnor. Elle stipule notamment que toute production se comporte comme une chaîne de production, dont la performance globale est celle de son maillon le plus faible. En d’autres termes, en sous-dimensionnant la hotline et les équipes « quincaillerie » (qui sont perçues comme telle), c’est toute la chaîne de production d’énergie IT (si l’on considère la DSI ainsi) qui est pénalisée. La seconde méthode, le Lean IT (pour laquelle je conseille la lecture de cet ouvrage¹), est basée sur la recherche du gaspillage et professe (entre autres) que la chaîne de production de valeur est tirée par le client final (étonnant qu’en informatique on ait mis 40 ans à s’en rendre compte), parce que c’est lui qui sait ce qui fonctionne ou non et qui subit de plein fouet la perte de productivité de la DSI. Autrement dit, quand la partie visible de la production IT (hotline et micro) tousse, c’est toute la DSI qui s’enrhume.

La seconde, et l’actualité récente est là pour nous le rappeler, est tout bêtement liée à la sécurité des SI. Par définition, les malwares les plus tordus arrivent par le terminal utilisateur. Or, un parc PC non maîtrisé, des terminaux non connus, des points d’entrée non sécurisés ou recensés sont autant de portes d’entrée à toutes les cochonneries qui nous valent des demandes de rançon pour obtenir des clés de déchiffrement hypothétiques. En d’autres termes, laisser l’entropie s’installer dans sa gestion de parc, c’est risquer la grosse fessée.

À 2 500 ans de distance, Sun Tzu et l’Anssi disent la même chose : sans maîtrise du terrain, point d’espoir de gagner la bataille. C’est la raison pour laquelle avant de déployer des PC à tout-va et de permettre le développement d’un parc de smartphones hyperhétérogène, avant de laisser dériver les PC biomed, les stations d’imagerie et j’en passe, la DSI ferait bien de muscler les équipes micro, d’investir dans des outils de gestion de parc et dans la formation ad hoc des équipes (SCCM est très performant pour autant que l’on sache l’utiliser et qu’on y ait dédié des ressources adéquates), sans oublier de dimensionner les équipes micro à leur juste valeur.

À une époque pas si lointaine, j’avais calculé que les ETP nécessaires pour gérer un parc de PC, en incluant le déploiement, les achats, la gestion des outils centralisés, etc., étaient de l’ordre de 1 ETP pour 500 PC environ. Certes, il est toujours possible de débattre de ce chiffre, mais voir des DSI atteindre un ratio de 1 ETP pour 1 000 PC a de quoi laisser songeur. Et encore, on ne compte pas les smartphones, les tablettes, etc. C’est pourquoi les DSI avec des parcs PC qui ont depuis longtemps dépassé ce ratio, en voyant venir un projet obligatoire de migration d’OS serveur, sentent le vide s’ouvrir sous leurs pieds.

Il ne vous reste plus qu’à faire vos comptes.

[1] Le Management Lean, Michael Ballé, Godefroy Beauvallet, éditions Pearson, 2013.