Tu as réussi à faire vivre ce truc pendant longtemps. Plus longtemps que ce que tout le monde veut bien reconnaître. Les prestataires se sont succédé. L'organigramme a été remanié plus d'une fois. Le trafic a évolué, le SaaS a fait son apparition, et à un moment donné, quelqu'un a décidé que « cloud-first » était une véritable philosophie. Et malgré tout ça, la plupart des matins, l'essentiel fonctionne toujours.
C'est une décennie d'instinct acquis à la sueur de ton front qui fait son effet, plus quelques passages chez Timmies au bon moment quand ça va mal. C'est du talent, pas de la chance. Donc rien de ce qui va suivre n'est une critique à ton égard. T'as réussi à monter un système qui marche avec des éléments que personne n'aurait choisis exprès.
Mais le temps s’en est discrètement mêlé pendant que tu ne regardais pas. À un moment donné, tout s’est fragmenté. Le réseau voit une version de la vérité. La sécurité en voit une autre. Les opérations voient une avalanche de tickets. La direction voit des risques et un retard accumulé, souvent après coup et généralement à ses dépens. Il y a plein de mots pour décrire ça, et le dictionnaire des synonymes ne propose que des termes peu flatteurs. Silo. Fief. Tu vois de quoi je parle. Du coup, quand quelque chose plante, la première chose que tout le monde se demande, ce n’est pas « comment on règle ça ? », mais « c’est le problème de qui ? ».
C'est le problème de qui ?
Ça se démonte pour des raisons que tu comprendras tout de suite :
- les outils ne parlent pas, ou pire encore, ils s'expriment sous forme de résumés bien ficelés qui masquent les informations dont tu avais vraiment besoin
- l'identité a été ajoutée après coup au lieu d'être intégrée dès le départ
- la politique est dans un document Word que quelqu'un a rédigé en 2019
- Les exceptions se sont accumulées jusqu'à ce que, un jour, elles deviennent discrètement l'architecture
- la piste d'audit ressemble plus à une rumeur qu'à un document officiel
Ce n'était la faute de personne, pas vraiment. Au départ, chaque élément n'était censé être qu'une solution « provisoire ». Puis Gary a changé d'équipe, le ticket que lui seul comprenait n'a jamais été clôturé, et ce qu'il était le seul à savoir manipuler est devenu ce que personne n'avait le droit de toucher. Et c’est exactement comme ça qu’un environnement pourtant parfait finit par devenir hanté. Pas le genre sympa, avec des bougies, une histoire victorienne et une comtesse tragique. Le genre où chaque demande de modification est accompagnée d’une étiquette d’avertissement et d’une prière silencieuse.
Qui tu vas appeler ?
Du coup, tu gères le réseau et la sécurité comme un tout, au lieu d'avoir deux services qui se renvoient des tickets d'un côté à l'autre. Un seul point d'entrée. Un seul triage. Un seul carnet de commandes. Une vue d'ensemble claire de ce qui a changé, de qui y a touché et pourquoi ça a été autorisé. Pas encore un tableau de bord de plus à ignorer. Une vraie responsabilité partagée, et c'est ça qui change vraiment la donne.
C'est exactement le rôle de Kyndryl Bridge : ta couche de workflow, généralement ServiceNow, se trouve juste en dessous, ce qui fait que « on peut le voir » se transforme enfin en « quelqu'un en est responsable ». L'échelle de la solution est vraiment utile ici. D’après les chiffres de Kyndryl, ça représente plus de 16 millions d’informations par mois et près de 3 milliards de dollars par an de productivité regagnée, ce qui est une façon très « corporate » de dire que tes collaborateurs arrêtent de passer leurs après-midis à chercher du contexte et commencent à les consacrer à réparer ce qui ne fonctionne pas.
Et franchement, peu importe que ton infrastructure soit bien rangée ou qu'elle ressemble un peu à un monstre de Frankenstein : un peu de Cisco, un peu d'Aruba, un peu de Fortinet, et trois trucs dont personne ne se souvient vraiment avoir achetés. La promesse reste la même dans tous les cas : un seul endroit fiable où l'état réel des choses est consigné, et où le nom de quelqu'un y est associé, avant que la prochaine « petite exception pour Gary » ne vienne gâcher le vendredi soir de tout le monde. Le rôle ISM, c'est de s'assurer que ça fonctionne pour une entreprise canadienne. Ta structure, ta réalité en matière de conformité, ta fenêtre de changement, quelle que soit la forme qu’elle prenne.
Quand ça marche vraiment, les gains sont discrets, et c'est justement le but. Les incidents se règlent plus vite, parce que personne ne perd les vingt premières minutes à essayer de comprendre ce qui a changé. On répond aux questions d'audit avec des preuves, plutôt qu'avec une réunion sur la réunion. Les relais se font plus rares, le réflexe « ça doit venir du pare-feu » s'estompe, et les migrations cessent de se transformer en fouilles archéologiques surprises. Même une invitation de Gary dans ton agenda ne te donne plus l'impression d'une mauvaise nouvelle. Rien d’extraordinaire. Juste moins de crises, et moins de gens dont le boulot est discrètement devenu une crise à lui tout seul.
Si tu cherches par où commencer concrètement, ce sont les quatre mêmes habitudes sur lesquelles toute cette série revient sans cesse. Fais un véritable état des lieux de ce que tu as, et mets-toi d’accord sur qui est responsable de chaque élément, avant d’essayer de régler quoi que ce soit. Traite tes journaux et tes données opérationnelles comme les informations sensibles qu’elles sont. Fais en sorte que la politique soit appliquée et mémorisée par le système plutôt que d’être juste un document, et laisse les exceptions expirer d’elles-mêmes. Et sécurise les données elles-mêmes, car l’identité, c’est le videur à l’entrée, mais les données ont quand même besoin de leurs propres verrous.
Fais ça, et cette impression de hantise disparaîtra. Le calme reviendra. Et quand tu pourras enfin avoir une vue d'ensemble du domaine, tu te rendras compte d'une chose : ce que tout ça t'a coûté, sans que tu t'en rendes compte. Et c'est justement là qu'on va en parler ensuite.
