Edzo Botjes: «L’efficacité s’oppose en quelque sorte à la résilience»

Sur quoi portent vos recherches? Quel est l’enjeu de la résilience?

Je m’intéresse à la résilience et aux questions de continuité et de risque, dans une perspective holistique allant de la technologie au design de l’organisation. J’enseigne l’architecture d’entreprise et je constate que l’on s’évertue à vouloir créer le programme parfait, les exigences parfaites, le produit parfait, alors que la réalité est chaotique et réserve des surprises. Je pense qu’il faut embrasser cette réalité. Considérons la cybersécurité: nous tendons à vouloir être assurés contre tout, à tout vérifier deux fois, à développer des contrôles sur tout... Cette approche montre de plus en plus ses limites. Plutôt que d’empêcher les événements de se produire, il faut faire en sorte que leur impact soit limité et même qu’ils se traduisent en impact positif.  C’est un enjeu pour toutes les entreprises et pour la société et c’est l’objet de mes recherches: qu’est-ce qui caractérise et comment développer des systèmes et des organisation adaptables, à l’écoute et capables d’apprendre en permanence. 

Qu’est ce qui nuit à la résilience des organisations?

Premièrement, les organisations doivent se montrer efficaces pour gagner de l’argent. Pour gagner en efficacité, il faut optimiser les processus, automatiser et réduire les variations. Un système efficace n’a pas beaucoup de marge et ne permet pas aux choses de se passer différemment, c’est un outil précis pour une fonction précise. Mais un tel système est aussi très fragile. Ainsi, les chaînes d’approvisionnement juste à temps sont efficaces, on a moins de tampon, moins de stock et on gagne davantage. Mais si quelque chose arrive, si la fabrique qui produit l’un des composants est arrêtée, toute la chaîne est interrompue. Il y a quantité de systèmes opérant de la sorte. L’efficacité s’oppose en quelque sorte à la résilience et joue contre l’efficience.

Le second problème c’est que pour être résilient et vraiment efficient, il faut disposer de différentes options, de différentes équipes, de différentes manières de faire les choses pour changer lorsque la situation le nécessite. Mais gérer cette variété est un casse-tête, si bien qu’on tend à simplifier et, ce faisant, on introduit de la fragilité. A vouloir à tout prix faire juste, on risque d’oublier ou de négliger ce qui n’est pas dans la cloche de la courbe de Gauss. Ce n’est pas pour rien qu’on préfère aujourd’hui que les agents du service client cherchent des solutions au lieu de suivre un script précis et rigide. 

Comment appliquer cette approche aux systèmes informatiques?

Je pense qu’il ne faut pas envisager les systèmes IT de manière isolée: on ne peut pas séparer la composante humaine de la composante IT, il faut plutôt envisager l’ensemble comme un système socio-technique. La façon dont travaille un développeur, la valeur qu’il apporte, et la personne à laquelle il apporte cette valeur sont étroitement liées. Nous retournons d’ailleurs à une approche plus humaine du design et des opérations. A l’image des DevOps où les personnes en charge du stack le sont aussi des opérations. Ou des petites équipes multidisciplinaires formées notamment des product owners et des représentants du business pour lesquels ils sont censés créer de la valeur. En réunissant ces compétences et en donnant de l’autonomie à ces équipes, on gagne en résilience. La résilience c’est la manière dont on réagit au changement: quelque chose se passe, comment on y fait face. Et l’anti-fragilité, c’est quand plus il se passe de choses, plus on en retire de la valeur.

Et comment préparer ces équipes à faire face et à devenir anti-fragiles?

Si vos équipes sont résilientes, l’étape suivante c’est de les bombarder de stress, aussi bien côté IT que côté business. Vous savez qu’ils sont entraînés, donc vous leur donnez des opposants plus forts de façon répétée, pour qu’ils s’adaptent en permanence et en ressortent plus forts. En prenant néanmoins garde de découpler ces épreuves du reste de l’organisation: on ne veut pas que tout le corps meure si quelque chose se passe mal. 

L’emploi des Chaos Monkeys correspond-il à ce type de stress vertueux?

Effectivement, les scripts façon Chaos Monkeys introduisent un stress dans votre système IT et vous permettent de mettre votre design à l’épreuve. Avez-vous une grosse pile de dominos ou des parties relativement découplées? Avez-vous suffisamment bien automatisé la réponse à des événements imprévus? Et, sinon, êtes-vous capable de réagir assez vite? C’est donc une bonne pratique à condition d’avoir déjà un bon niveau de résilience. Il en va de même pour les programmes de bug bounty, qui reviennent à dire au monde entier: «frappez-moi!». Si vous êtes résilient c’est un bon entraînement, si vous ne l’êtes pas, ça peut faire mal… Ces méthodes ne concernent cependant que l’IT, il faut aussi concevoir des tests pour les autres dimensions.

L’organisation en équipes produit et DevOps avec une architecture de microservices est-elle la recette de la résilience?

Je pense que la forme ultime de résilience c’est même de ne pas avoir d’équipe du tout, et de disposer d’un écosystème de services et de responsabilités. Avec, lorsque quelque chose arrive que vous n’attendiez pas, des gens dans l’organisation qui s’emparent du sujet, le règlent et s’en vont. Alors seulement, vous vous adaptez à l’imprévu. Toute décision d’affecter telle responsabilité ou tel système à une équipe spécifique introduit déjà de la fragilité. On entend beaucoup parler de préparation, de plans de réponses et de task force mobilisées en cas d’incident. Cette approche ne correspond pas à l’approche anti-fragile, qui serait plutôt que tout le monde est susceptible d’intervenir sans manuel à appliquer. C’est ce que voit dans les rares entreprises qui adoptent l’holocratie: au lieu d’une hiérarchie, on a plutôt des domaines au sein desquels des groupes se forment de manière spontanée pour résoudre les problèmes, sans attendre qu’un manager ne leur dise de le faire.

A propos d'Edzo Botjes

Edzo Botjes se décrit comme un architecte de l'antifragilité. Il a publié son mémoire de maîtrise, à l'Antwerp Management School, intitulé «Defining Antifragility and the Application on Organisation Design» en 2020. Il a également publié ses travaux en 2021 dans un article de l'IEEE. Actuellement, Edzo Botjes combine son travail chez les clients avec sa passion pour l'enseignement de l'architecture d'entreprise à l'Université des sciences appliquées d'Utrecht et son doctorat à l'Université ouverte des Pays-Bas, où il effectue des recherches à l'intersection de la sécurité de l'information, de l'apprentissage organisationnel et de la cyber-résilience.

En octobre 2023, il intervenait lors de la 10ème conférence Swiss Cyber Storm à Berne. Sa présentation est disponible en vidéo: "How to deal with the inevitable chaos of the cloud: on humans and reality"