Ce que les développeurs doivent apprendre des grandes pannes de 2016

Lorsque la compagnie aérienne SouthWest Airlines a souffert d’une panne de 12 heures de sa plateforme en ligne, personne n’aurait eu envie d’être à la place des développeurs de la société. La compagnie a été obligée d’annuler 2.300 vols, provoquant les retards de 4.500 personnes et occasionnant une perte de revenus estimée à 54 millions de dollars – sans parler de sa réputation, quelque peu écornée.

Michael Butt, directeur du marketing chez Big Panda, a collecté ses propres statistiques – ainsi que d’autres issues de pannes majeures sur le Web – pour mettre en lumière un fait marquant : les entreprises et leurs équipes de développement ne raisonnent pas en s’appuyant sur une stratégie de conception d’applications qui pourrait minimiser l’ampleur des pannes.

Sa recommandation première est d'arrêter de penser que l’on doit absolument développer une application qui ne tombe jamais en panne. Au contraire. Il faut en concevoir une qui réduise l’ampleur de la panne et son impact.

« On rencontre  des entreprises encore prises aux dépourvues par des pannes très lourdes », constate-t-il. « Cela n’est pas surprenant. Les transformations induites par le numérique sont plus complexes, et au regard de l’ampleur du changement, on peut s’attendre à d’éventuels dysfonctionnements. Mais il est assez déroutant de constater que les entreprises ne font pas grand chose pour essayer d’anticiper des pannes vraiment handicapantes. »

Pour Michael Butt, cette situation est le résultat d’un degré élevé d’interdépendance des applications, et du fait que les entreprises n’intègrent pas la résilience par défaut. « Que fait une entreprise pour devenir plus résiliente ? », interroge-t-il. « Si l’on observe la plupart des entreprises du Web, on remarque qu’elles ne bâtissent pas des systèmes 100% résilients, mais qu'elles ont intégré le fait qu’un certain niveau de panne est possible. »

Pour les développeurs et les équipes de tests, cela signifie donc qu’il faut collaborer avec les métiers et statuer précisément sur la nature critique d’un composant applicatif (celui qui ne doit donc pas tomber en panne) et y dédier temps et technicité. Mais il est tout aussi important d’identifier quels composants peuvent tomber en panne. « Un développeur ne peut plus imaginer que 100% d’une application ne doive pas tomber en panne. Ce n’est pas réaliste. »

Pour se faire à cette idée, il recommande de commencer par identifier le premier tiers d’une application - celui qui doit fonctionner en permanence.

Les développeurs et les équipes de test ont ainsi besoin de faire une veille permanente sur les composants clés d’un système. En s’interrogeant par exemple sur les demandes des métiers, on peut identifier sur quel(s) composant(s) on doit passer le plus temps.