Embrassez le risque, pas le danger !

Le vieil adage informatique "Ne pas toucher un système qui marche !" paralyse les entreprises. La prise de risque est nécessaire pour avancer. Il faut circonscrire le danger et créer de la confiance.

Embrassez le risque, pas le danger !

Comment innover sans prendre de risques ? Tout le monde convient que développer un nouveau produit, tenter une nouvelle approche, un nouveau business model, contient une part de risque.

Pourtant, dans le monde de l'IT, dès qu'on parle de risque, les visages se ferment, les traits se crispent... Prendre un risque va à l'encontre du vieil adage : "Ne pas toucher un système qui marche !"

Forts de cet axiome, des générations d'informaticiens assurant le run ont repoussé, retardé, ralenti le rythme des innovations et ont fini par convaincre métiers et directions générales qu'il ne fallait surtout pas prendre de risques. Mettre en prod une nouvelle feature sur un site qui augmentera la performance ou la rentabilité alors qu'on est en pleine période d'affluence, vous n'y pensez pas, voyons ?!

Nous nous sommes tous, collectivement, persuadés que l'IT d'une entreprise est un château de cartes, susceptible de s'effondrer au moindre souffle de vent. Que retirer ou ajouter un bout de logiciel ici ou là revient à jouer à Badaboum, au Mikado, à tous ces jeux où il suffit de frôler une pièce pour que tout s'écroule.

En IT comme ailleurs, toutefois, c'est la prise de risque qui fait avancer : parier sur le Cloud public, miser sur la valorisation de la donnée ou encore... déployer une nouvelle feature sur un site qui augmentera la performance ou la rentabilité alors qu'on est en pleine période d'affluence.

C'est risqué, mais pas dangereux. Si tout est fait correctement.

Le problème vient en fait de la confusion entre risque et danger.

Faire de la plongée sous-marine est un sport à risque. Les dangers sont nombreux : accidents de décompression, hypothermie ou narcose entraînant la noyade, surpression pulmonaire, hyperoxie ou hypoxie (excès ou manque d'oxygène)... Les cours que suivent les plongeurs et l'encadrement fourni par les clubs de plongée sont là justement pour prévenir ces dangers. Il s'agit d'en comprendre les mécanismes afin de s'équiper en conséquence et d'adopter les bons comportements.

Les mêmes principes s'appliquent au parachutisme, à l'escalade, au ski extrême...

La mise en production d'une application ou d'une mise à jour devrait suivre les mêmes règles. C'est risqué oui, mais le danger peut être circonscrit, en industrialisant au maximum, en adoptant une chaîne CI/CD intégrant des tests automatisés et en prévoyant un mécanisme de roll-back, par exemple.

Bien sûr, cela nécessite de la confiance.

Les CTO doivent avoir confiance dans la plateforme technologique qu'eux et leurs équipes ont mise en place. Les CIO doivent avoir confiance dans les CTO. Les directions générales doivent avoir confiance dans leurs CIO et CTO.

Cette confiance se construit. De la part de ceux qui réalisent, il s'agit de montrer qu'on peut construire un système industriel, automatisé partout où ça peut l'être, et à l'épreuve d'un code qui présenterait des défauts. Ou d'un serveur qui tombe, pour une raison X ou Y. C'est le principe même des architectures Cloud : on sait qu'un serveur peut tomber en panne, alors on met en place des mécanismes pour minimiser l'impact et assurer la continuité du service.

Netflix a poussé ce paradigme jusqu'au bout, et inventé le programme Chaos Monkey, pour tester la résilience de son IT de production. Chaos Monkey choisit et éteint, de façon aléatoire, un serveur durant ses heures normales de production. "Sachant que cela se produirait fréquemment, les ingénieurs ont décidé de mettre en place une redondance et une automatisation des processus afin de survivre à de tels incidents, sans affecter les millions d'utilisateurs", explique Netflix, qui a ainsi donné naissance à la discipline du "Chaos Engineering".

Cette confiance se construit aussi et surtout par une attitude bienveillante du management. Il s'agit de montrer que les paris sont encouragés, tant que la prise de risque est documentée (les dangers sont connus et prévenus) et vise à optimiser le business.

Il n'est certainement pas évident de parvenir à un tel niveau de confiance dans les systèmes et les hommes que la prise de risque est souhaitée, valorisée. Mais sans cela, il sera encore plus difficile de s'adapter aux changements.

Chaos engineering - Wikipedia
Pour en savoir plus sur le "Chaos Engineering"
Olivier Rafal on LinkedIn: #wenvision #engineering #culture
Le vieil adage informatique “Ne pas toucher un système qui marche !” paralyse les entreprises. La prise de risque est nécessaire pour avancer. Il faut...
Réagissez à ce billet sur LinkedIn !

Génial ! Vous vous êtes inscrit avec succès.

Bienvenue de retour ! Vous vous êtes connecté avec succès.

Vous êtes abonné avec succès à WENVISION.

Succès ! Vérifiez votre e-mail pour obtenir le lien magique de connexion.

Succès ! Vos informations de facturation ont été mises à jour.

Votre facturation n'a pas été mise à jour.