ITIL 0 : Quand le chaos informatique était une compétence essentielle
Imaginez un monde où les disquettes faisaient office de disques durs portables, où les mainframes trônaient comme des dieux dans des salles climatisées, et où les techniciens IT tapaient des commandes mystérieuses sur des claviers bruyants, donnant l’impression de sauver la planète à chaque coup d’Entrée. C’était les années 80. L’ITSM, tel qu’on le connaît aujourd’hui, n’existait pas encore, et parler de "transformation numérique" aurait fait hausser les sourcils — on parlait plutôt de "ne pas tout casser en bidouillant".
Bienvenue dans l’univers d’un hypothétique "ITIL 0", un âge d’or où l’instinct de survie IT dominait tout, et où les techniciens jonglaient entre post-it, scripts en COBOL, et prières silencieuses pour que le système redémarre avant que le patron n’arrive.
Le chaos glorieux des années 80 : Quand le mainframe était Dieu
Les années 70 et 80 étaient dominées par des monstres technologiques comme les IBM System/370, les VAX-VMS de Digital et quelques joyaux obscurs qui demandaient autant d’électricité qu’un village entier. Ces machines géantes, aussi discrètes qu’un avion au décollage, étaient logées dans des salles ultra-sécurisées, avec un climat soigneusement contrôlé — pour les machines, pas pour les humains. (Le confort du technicien passait après la température idéale du processeur.)
Les départements IT fonctionnaient comme des sanctuaires. Pas question pour un employé lambda d’y mettre les pieds, sauf s’il était prêt à affronter le regard glacial d’un technicien penché sur un terminal monochrome. Tout était centralisé sur ces mainframes, et chaque panne ressemblait à l’apocalypse : "Attention, si le batch de paie ne passe pas, c’est la révolution dans les couloirs !"
La gestion des incidents : Post-it, stress, et chocolat Noir
"Si ça marche, on touche pas. Si ça casse, on improvise."
Quand une panne survenait, les techniciens recevaient des "tickets", mais ces tickets n’avaient rien d’informatique. Cela pouvait être :
Les interventions, quant à elles, dépendaient de deux choses :
Pas de système de priorisation, pas d’outils modernes pour suivre les incidents : juste de la débrouille et un soupçon de magie noire.
Les configurations : Où sont passées mes notes ?
Les configurations des systèmes étaient notées à la main, souvent sur des carnets ou des fiches rangées dans des classeurs poussiéreux. Quand une pièce tombait en panne, le responsable des configurations était souvent ce collègue qui savait "tout par cœur". (Mais si ce collègue tombait malade, c’était la chasse au trésor dans la salle machine.)
Le pire cauchemar ? Découvrir que quelqu’un avait "optimisé" une configuration sans prévenir, plongeant l’entreprise dans une panne interminable. Pas de "rollback" facile : ici, chaque erreur coûtait du temps, de l’argent, et souvent, une demi-journée de téléphonie pour calmer les nerfs des utilisateurs.
Recommandé par LinkedIn
Les changements : On croise les doigts
Quand une modification technique devenait inévitable, c’était l’angoisse. Les validations des changements ? Ça se faisait autour de la cafetière, entre deux blagues sur les "bandes perforées". Les techniciens savaient que chaque changement pouvait potentiellement déclencher un cataclysme informatique. Mais parfois, faute de temps, on improvisait :
Les outils des années 80 : Du système D à la vitesse de l’escargot
Les outils ? Simples, rudimentaires, et souvent bricolés. Les scripts maison en COBOL effectuaient le travail répétitif, tandis que les techniciens maintenaient des tableurs (parfois encore sur papier) pour suivre les incidents et les configurations.
Les machines étaient si lentes que lancer un traitement équivalait à prendre une pause café prolongée. (Fun fact : certains techniciens lançaient leurs batchs juste avant de partir déjeuner, espérant qu’ils soient finis au retour.)
Quant à l’analyse des logs, elle se faisait à la loupe. Littéralement. Les techniciens lisaient des kilomètres de journaux pour trouver l’erreur fatale, souvent en jurant contre l’inventeur du système.
ITIL 0 : Le manuel que nous n’avons jamais eu
Si un "ITIL 0" avait existé, il aurait ressemblé à un guide de survie écrit sur une vieille Remington. Pas de jargon, pas de buzzwords, juste des règles pragmatiques :
Pourquoi ITIL était inévitable
Ce chaos organisé, bien qu’héroïque, montrait ses limites. Les pratiques variaient trop d’une entreprise à l’autre, et la dépendance aux individus (souvent surnommés "le magicien de la salle machine") rendait les systèmes fragiles. ITIL, lorsqu’il est arrivé en 1989, a été un souffle de soulagement (et un casse-tête à mettre en place, mais c’est une autre histoire).
Un zeste de nostalgie
"C’était le bon vieux temps… sauf quand ça tombait en panne."
En repensant à ces années 80, on ne peut s’empêcher d’admirer l’ingéniosité de ces pionniers de l’informatique. Oui, tout était plus compliqué. Oui, les outils étaient rudimentaires. Mais chaque solution trouvée ressemblait à une petite victoire.
Et aujourd’hui, alors que nos systèmes sont plus automatisés que jamais, on se souvient avec tendresse de cette époque où tout reposait sur une combinaison de génie, de bricolage, et de café (beaucoup de café).
ITIL 0, c’était l’ère des héros discrets de la salle machine. Un âge d’or, un peu chaotique, mais résolument inoubliable.