Tout le monde se remémore les déboires technologiques subis l’an passé par France Télécom, Bouygues Télécom et la SNCF avec leurs outils de production. Au point que 2004 restera peut-être dans les esprits l’annus
horribilis des pannes informatiques. Quels constats peut-on en tirer ? Exercice difficile, étant donné le peu d’informations disponibles. Plusieurs commentaires s’imposent néanmoins.D’abord, un fait frappant : les responsables des entreprises ne savent pas parler des pannes, ni les journalistes poser les bonnes questions. Visiblement, la culture de la production informatique est inexistante en France. Et
des gens s’imaginent encore qu’un système à tolérance de panne ne sera jamais impliqué dans une interruption de service ! Comme si l’on ne pouvait avoir d’accident avec une voiture puisqu’elle ne tombe pas en panne…C’est la négation même du métier d’exploitant. En bref, il suffirait de mettre en ?”uvre des machines qui marchent, avec des programmes fonctionnellement testés, et tout irait bien. Sans chauffeur ?Deuxième remarque : ‘ On ne connaît pas l’origine de la panne ‘ est un leitmotiv inquiétant. Peut-être a-t-on accumulé des systèmes opérant sans contrôle, et sans que les éléments
en production ne renseignent sur leur état. Pas de nouvelle, bonne nouvelle ! C’est la négation même de la démarche de production industrielle, fondée sur la loi de Murphy** : envisager que tout système peut et doit tomber en panne. Et
donc évaluer ce que cela occasionnera sur le service rendu à l’utilisateur. Hélas, il semble que l’on ne surveille pas ce qui doit l’être, car on ne sait pas ce qui est important en termes de service. Le chauffeur de la voiture est
aveugle !
Y a-t-il un pilote à la DSI ?
On peut légitimement se poser la question : qui est responsable du service ? Qui exige que les machines et les programmes renseignent sur leur état ? Qui oppose son veto au passage en production d’éléments non
pilotables ? Qui impose que l’on envisage des scénarios de pannes ? L’ingénierie de production de service doit acquérir ses lettres de noblesse, et les fournisseurs de la production (études et système) ont à tenir compte de ces exigences.Autre point important, mais plus délicat : les interventions sensibles sur les éléments de production ?” évolutions de systèmes (‘ upgrade ‘), mises à jour de
correctifs ?” seraient menées sans grande considération des impératifs de service. Des notions industrielles telles l’analyse d’impacts ou la capacité à mener des ‘ retours arrière ‘ ne
semblent pas très élaborées.La conservation des capacités à produire serait parfois mise en danger. La capacité à reconstituer des états propres de données paraît trop faible. Alors, à quoi sert d’avoir des systèmes coûteux à tolérance de panne ? Si la
donnée est corrompue sur mon site principal, elle le sera sur mon site secondaire, d’autant plus si le système est rapide ! Le chauffeur n’a pas le permis !
Difficile en phase de test de reproduire la réalité
Dernier point, qui n’aide pas la tâche du producteur : nous sommes face à des environnements multiniveaux (n-tiers) complexes, avec des plates-formes en interaction et des automatismes transversaux. Très difficile d’avoir un
environnement de test reproduisant la réalité… Autrement dit, à l’encontre des systèmes traditionnels, il faut parfois tester en production, quitte à baisser la garde en termes d’automatismes (effet Tchernobyl).De plus, la pression concurrentielle pousse à mettre très vite en production de nouvelles applications. Le risque est donc fort de subir des incidents en exploitation sans savoir y faire face.Conclusion : produire un service, ce n’est pas uniquement avoir ‘ une informatique qui marche ‘, mais aussi savoir quoi faire quand elle ne marche pas !* Consultant au sein du cabinet Sievers Consulting France** Selon cette loi, tout ce qui est susceptible de mal tourner tournera mal. En particulier quand on ne le veut pas ?” au cours d’une démonstration, par exemple.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
