Le 26 décembre 2023, pour beaucoup, c'est le lendemain de Noël. Pour certains utilisateurs, ce jour restera gravé comme LE jour où ils ne pouvaient plus utiliser leur superbe Ford à cause... d'une mise à jour logicielle.
Pourquoi est-ce que je parle de résilience ?
C'est le 26 décembre, qu'une image pop sur X (anciennement Twitter) montrant un écran/tablette dans une voiture où il est indiqué que la voiture ne peut être conduite, car une mise à jour logicielle a échoué et que le propriétaire du véhicule doit appeler ou se rendre dans un concessionnaire pour régler le problème !
L'occasion parfaite pour vous parler d'un concept souvent oublié dans les projets ou, à l'inverse, beaucoup trop mis en avant dans d'autres : la résilience
La résilience, un concept souvent négligé
Le principe de la résilience est simple : il consiste à essayer de tenir face à n'importe quel sinistre possible. Si ma maison résiste aux vents des tornades, ou que je suis capable de reconstruire une maison en moins de temps qu'il n'en faut pour que cela m'embête, on peut considérer que je suis résilient dans les deux cas.
En informatique et en cybersécurité, c'est le même combat. Si mon site internet résiste aux attaques ou aux pannes informatiques, ou que je suis capable de recréer mon site à l'identique à côté en moins de temps que cela ne nuit à mon activité, alors je suis résilient.
Vous l'aurez compris, la résilience est très dépendante du contexte de votre application. Si je développe une application de gestion des appels d'urgence médicale, je dois être en mesure d'être suffisamment résilient pour ne jamais manquer un appel et donc être (quasiment) disponible tout le temps. En revanche, si mon application est une application de réservation de moules à gaufre, ce n'est pas très grave si elle n'est plus disponible pendant quelques instants.
La résilience est un concept lié à la disponibilité, un fameux élément du triangle de la cybersécurité, avec sur chaque pointe la confidentialité, l'intégrité et la disponibilité.
L'erreur de Ford
Ford a commis l'erreur de penser qu'il était acceptable pour ses clients de devoir se rendre à un concessionnaire ou les appeler lorsqu'une mise à jour de leurs véhicules échoue. C'est une grossière erreur, car la voiture, moyen de transport le plus attaché à l'indépendance, peut être utilisée dans n'importe quel contexte. On peut se servir de notre voiture pour faire des courses ou amener mamie à l'hôpital en toute urgence. Imaginez les conséquences dans le deuxième cas si, en panique, vous ouvrez votre unique voiture, la démarrez et tombez sur ce message d'erreur !
Ford aurait dû anticiper ce cas d'usage et fournir un moyen de revenir à la version précédente, permettant ainsi aux propriétaires de conduire a minima le véhicule qu'ils ont acheté.
La résilience doit être pensée tout au long du projet, en réunissant le client et en comprenant les besoins métier pour définir les cas d'usage de l'outil et spécifier les besoins et utilisations critiques. Se servir de son véhicule est clairement un besoin critique qui aurait dû être identifié et défini pour éviter de tomber dans cette impasse.
L'erreur d'en faire trop
Ford a commis l'erreur de ne pas avoir suffisamment pensé à la résilience dans ses véhicules, mais de l'autre côté de la ligne, on trouve des personnes qui souhaitent être résilientes à tout ce qui bouge.
Votre projet personnel, avec trois utilisateurs par an, n'a certainement pas besoin d'être résilient à tous les niveaux et d'avoir un temps de disponibilité à 99,999999%. Il est probable même que votre projet puisse s'arrêter pendant plus de 48 heures sans problème.
Le problème d'en faire trop ? La résilience, ça coûte cher ! Planifier et tester sa résilience, c'est du temps et des ressources qui peuvent être gaspillés si vous cherchez à être résilient face à un risque qui ne vous concerne pas.
Le juste milieu
Bon, d'accord, il faut être résilient, mais pas trop quand même, mais tout de même un peu. On ne sait plus trop sur quel pied danser là !
En réalité, la solution est de vous placer là où il faut. Prenez le temps et faites-vous accompagner par un ou des experts de la gouvernance, du risque et de la conformité pour identifier les risques métier sur votre disponibilité qui vous concernent et vous impactent. Vous n'avez pas besoin d'être résilient à la chute d'un fournisseur de services cloud si celui-ci vous promet une remise en état en moins d'une journée et que de votre côté, les utilisateurs peuvent se passer de votre application pendant plus de 24 heures !
Par ailleurs, il vaut mieux prendre du temps pour tester sa résilience que de passer du temps à penser à tous les cas possibles qui ne vous arriveront jamais. Notre temps n'est pas illimité, utilisons-le avec parcimonie sur les éléments où nous apportons de la valeur !
Vidéo
Retrouvez bientôt ce texte sous un podcast et une vidéo disponible sur le site smartratel.fr