L'analyse des causes profondes dans le développement de logiciels: pourquoi il n'y a pas d'erreurs de la part des chefs de projet* et des pilotes

Les pilotes sont responsables de l'accident.

Lors d'un crash d'avion, les médias écrivent très souvent, peu après l'événement, que des erreurs de pilotage sont à l'origine de l'accident. Ce fut le cas lors du crash de la Tante Ju 52 du 4 août 2018 près de Flims (GR), qui a fait 20 morts. Lorsque le rapport final du Service d'enquête suisse de sécurité (SESA) sur le crash a été publié début 2021, j'ai été étonné des gros titres médiatiques tels que « Des erreurs de pilotage ont conduit au crash de "Tante Ju" en 2018 ». (SRF)

Toutes les causes et tous les facteurs, en particulier ceux liés aux causes directes de l'accident, indiquent clairement, à première vue, une erreur de pilotage. Mais une question importante se pose alors: pourquoi un équipage d'avion peut-il en arriver là, prendre autant de risques et ignorer aussi longtemps les règles très strictes et les principes juridiques de l'aviation, sans que les autorités n'interviennent ? Les erreurs sont-elles peut-être dues au système?

Finger Pointing: pas d'erreur de pilote ou de chef de projet

Les problèmes constituent en effet très souvent des obstacles dans les projets, qui doivent être éliminés le plus rapidement possible afin d'atteindre une situation cible cohérente. Mais pour pouvoir résoudre efficacement un problème, il faut d'abord savoir l'identifier. Cela n'est possible que si une organisation entretient et vit une culture ouverte concernant les problèmes et les erreurs, et qu'elle est disposée à tirer les leçons des erreurs découvertes afin de s'améliorer à long terme. Il ne s'agit jamais de désigner d'éventuels coupables par ce que l'on appelle le « finger pointing », mais d'identifier les erreurs dans le système, de les analyser et de trouver ensemble des solutions durables qui empêchent les erreurs ou les problèmes de se reproduire.

Chez Apps with love, les chefs de projet sont les pilotes des projets. Ils planifient, coordonnent, gèrent et communiquent toutes les activités liées aux projets et sont très souvent les interlocuteurs directs de nos clients. Ils ont la lourde responsabilité de livrer les projets dans les délais, le budget, la portée et la qualité impartis. Il s'agit également d'offrir une bonne expérience aux clients et de garantir leur satisfaction. Tout cela est un art et, comme je le sais par mon expérience personnelle, très exigeant.

L'idée d'écrire ce blog post est née d'une part du rapport publié par la SUST et du finger pointing médiatique, et d'autre part, nous avons reçu au même moment plusieurs annonces d'erreurs logicielles concernant une application que nous avons développée et mise en service : Environ un mois après la mise en production d'un projet important, une, puis plusieurs erreurs logicielles critiques (appelées incidents) ont été découvertes par la cliente et nous ont été signalées. Vous pouvez lire ci-dessous ou en détail sur la page Support les différentes étapes de l'analyse et de la résolution de tels incidents.

En raison de la pression du temps qui prévaut souvent lors de la correction d'une erreur de logiciel dans un système de production et du manque de temps pour découvrir systématiquement le problème effectif, seuls les symptômes sont souvent corrigés. La cause réelle du problème reste en place, avec la forte probabilité que la même erreur logicielle ou une erreur similaire se reproduise bientôt.

C'est précisément ce qui s'est passé dans notre cas. Peu de temps après avoir réparé le logiciel et l'avoir réinstallé, une nouvelle erreur, relativement similaire, a été signalée à notre équipe d'assistance. Le jeu a recommencé.

Pour trouver la cause du problème, nous avons décidé de procéder à une analyse complète des causes profondes. L'intention sous-jacente était d'améliorer à long terme la qualité de nos projets, mais aussi celle de notre organisation (amélioration continue). Une démarche plutôt laborieuse, complexe et parfois même émotionnelle. Maud Cottier, mon ancienne collègue de la gestion de la qualité, et moi-même avons entrepris d'appliquer la méthodologie que nous connaissions tous deux depuis nos études à un "vrai" projet.  

Qu'est-ce qu'une analyse des causes profondes (RCA)?

Une analyse des causes premières (ou analyse des causes d'erreur) est un processus méthodique visant à identifier les problèmes sous-jacents d'un événement et sert donc d'analyse rétrospective d'un incident. Il s'agit d'examiner quand, comment et pourquoi un problème est apparu. On part du principe que les problèmes s'inscrivent toujours dans une chaîne de causes et d'effets et qu'un problème ne peut pas être résolu tant que la cause n'a pas été éliminée à la racine (en anglais : root). 

Les questions fondamentales suivantes se posent alors, auxquelles la réalisation d'une ACR devrait permettre de répondre:

• Quelles ont été les causes de ce(s) problème(s)?

• Quelle est la séquence et la relation entre les causes?

• Pourquoi y a-t-il eu une erreur?

Méthodes pour effectuer une analyse des causes profondes.

Pour réaliser une analyse des causes profondes, il est possible de choisir entre différentes méthodes. La méthode la plus courante est la méthode des 5 pourquoi ou des 5 pourquoi, complétée par une représentation visuelle des causes dans un diagramme de causes et d'effets.

Méthode des 5 pourquoi

La méthode des 5 pourquoi est une procédure populaire pour une analyse des causes premières et un outil pour l'analyse des problèmes et de leurs causes. Elle consiste à examiner avec les protagonistes* un problème limité en leur demandant cinq fois ou plus "pourquoi cela s'est passé ainsi". Les questions "pourquoi?" (il peut y en avoir plus de cinq, le nombre est symbolique) doivent finalement conduire à la cause du problème.

La méthode des 5 pourquoi trouve son origine dans la gestion de la production et est un instrument au sein de l'assurance qualité pour l'analyse des causes des processus et des systèmes qui peuvent très souvent être linéaires, causaux et compliqués. La méthode a été inventée par Toyoda Sakichi et est aujourd'hui incontournable dans toute la philosophie Lean.

L'application de la méthode des «5 pourquoi» est simple et s'apprend très rapidement. Dans un premier temps, le problème ou la situation est formulé(e) de manière simple. Ensuite, le problème est expliqué aux protagonistes et l'on commence par la première question «pourquoi ?». Les questions «Pourquoi?» sont répétées jusqu'à ce que la cause première, c'est-à-dire l'origine ou la racine du problème initial, soit identifiée.

Représentation visuelle des causes avec le diagramme cause-effet.

Le diagramme de causes et d'effets permet de classer, de structurer et de représenter visuellement les causes potentielles d'un problème. Les causes sont identifiées et mises en relation. L'une des formes de représentation des causes des problèmes de qualité les plus utilisées dans la gestion de la qualité est le diagramme d'Ishikawa, également appelé diagramme en épi, qui permet de représenter de manière simple et claire les causes et les relations entre elles.

Dans notre cas, le contenu du diagramme en épi résulte de l'analyse de l'incident et des résultats de la méthode des 5 pourquoi. Les résultats de l'analyse, c'est-à-dire les causes qui pourraient avoir conduit au problème, sont maintenant attribués aux différentes catégories - matériel, méthode, gestion, environnement, machine, personne - à l'aide de flèches. On obtient ainsi de petites branches à l'intérieur de ces catégories, également appelées arêtes de poisson.

Objectifs de l'analyse des causes profondes des incidents survenus

Avant de commencer l'analyse des causes profondes, nous nous sommes à nouveau demandé ce que nous voulions exactement obtenir en réalisant l'ACR. Pour ce faire, nous nous sommes à nouveau penchés sur la situation de départ: Environ un mois après la mise en production d'un projet important, une, puis plusieurs erreurs logicielles critiques ont été découvertes par la cliente et nous ont été signalées.

Voici les questions que nous nous sommes posées et auxquelles nous avons voulu répondre:

1. Quels sont les facteurs qui ont conduit Apps with love à livrer un incrément logiciel qui ne fonctionnait pas?

2. Quels sont les points que Apps with love peut améliorer à long terme pour éviter un tel incident?

3. Pouvons-nous réduire le risque pour nous, en tant qu'entreprise, à long terme grâce à l'analyse de la cause racine?

Procédure et instructions pour effectuer une analyse des causes profondes

Comment avons-nous procédé pour effectuer l'analyse de la cause racine dans notre exemple?

Etape 1: Décision de réaliser l'ACR

Il a été décidé en commun de réaliser une ACR dans le but d'améliorer continuellement l'organisation et d'établir des méthodes d'amélioration inhabituelles. L'équipe de projet RCA et le mandat ont été définis.

Etape 2: Définition du mandat de projet de l'ACR

Il était important de définir le mandat de projet de la réalisation de l'ACR, de fixer des objectifs clairs, de fixer un délai, de le délimiter par rapport à d'autres projets en cours simultanément et de réaliser l'ACR de manière aussi indépendante que possible. L'équipe et les protagonistes, les outils et les instruments d'analyse ainsi que la méthode à appliquer ont été définis.

Etape 3: Elaboration de la base de données et documentation chronologique de toutes les informations

L'étape 3 était la plus longue, mais aussi la plus importante. Il s'agissait ici de documenter toutes les données en vue d'une analyse ultérieure.

Voici donc ce que nous avons fait: 

• Documentation chronologique des incidents signalés

  • Les informations partiellement manquantes sur les incidents ont dû être traitées et complétées par des entretiens avec certains collaborateurs du projet: Nous avons une fois de plus pris conscience de l'importance d'une documentation continue pour la traçabilité.

• Analyse des tâches exécutées et développées et comparaison avec les exigences du produit

  • Analyse des discussions et commentaires dans notre outil de communication Slack

  • Reverse Engineering et analyse des erreurs logicielles déjà corrigées ainsi que leur documentation ultérieure

  • Analyse et documentation chronologique des Software-Releases et déploiements sur les différents environnements de développement

  • Analyse des rétrospectives de projet effectuées et du débriefing de projet

La mise à jour nous a aidés à cerner et à délimiter les problèmes.

Etape 4: Réalisation d'ateliers avec les différents protagonistes du projet et analyse commune des causes à l'aide de la méthode des 5 pourquoi

Au cours de l'étape 3, nous avons pu classer les problèmes grâce à une base de données détaillée et élaborée. Cela a servi de base aux ateliers avec les différents protagonistes. Avec la méthode des 5 pourquoi, les problèmes délimités sont passés en revue un par un et les causes sont décrites et documentées au méta-niveau du point de vue des protagonistes. Il est important de noter que la méthode des 5 pourquoi ne dit pas qu'après le cinquième "pourquoi?", la cause est claire. Il se peut très bien qu'il faille poser 7 questions "pourquoi?" ou plus.

Etape 5: Cluster toutes les causes à l'aide du diagramme en épi

Après les ateliers avec les protagonistes, les causes ont pu être regroupées au méta-niveau et représentées visuellement à l'aide du diagramme en épi afin d'obtenir une vue d'ensemble globale des causes qui ont contribué aux événements.

Etape 6: Déduction des recommandations et des mesures possibles pour l'amélioration

L'étape suivante a permis de formuler les premières recommandations et mesures à partir de la documentation des ateliers 5 pourquoi, des causes identifiées et de leur représentation visuelle. Il a été passionnant de constater que les premières mesures ont déjà été initiées et abordées par l'équipe de projet pendant la réalisation d'une ACR, avant même la conclusion de l'ACR proprement dite. Ce qui semble se produire plus souvent lors de la réalisation d'une ACR.

Etape 7: Présentation des mesures à l'équipe de projet puis aux différents domaines spécialisés

Une partie importante de l'ACR est la présentation des recommandations et des mesures possibles aux différents domaines spécialisés et aux équipes ainsi que leur transmission pour traitement ultérieur par ces derniers. 

Etape 8: Vérification de la mise en œuvre des recommandations et des mesures

Il est important de vérifier à intervalles réguliers la mise en œuvre des recommandations et des mesures, de s'enquérir du statut et de documenter en permanence les solutions d'amélioration. Les recommandations d'une ACR donnent très souvent lieu à l'amélioration et à l'adaptation de processus.

Conclusion: Amélioration continue des processus de développement logiciel grâce à l'analyse de la cause racine

Pour améliorer la qualité au sein d'une organisation, les causes réelles d'un problème doivent être identifiées, analysées et traitées. Des techniques telles que la méthode des 5 pourquoi et le diagramme en arête de poisson sont utilisées pour éliminer durablement les erreurs et optimiser les processus et leur déroulement.

La décision d'effectuer une analyse des causes profondes après un incident doit être bien réfléchie, car cela ne vaut pas toujours la peine, en particulier dans le développement de logiciels où de nombreuses choses sont toujours nouvelles. Dans notre cas, la décision de procéder à une ACR s'est vite imposée, car après la première correction des erreurs logicielles signalées, d'autres erreurs logicielles ont été signalées.

La réalisation de l'ACR nous a permis non seulement d'établir une nouvelle méthodologie au sein de l'entreprise, mais aussi d'identifier certaines des causes qui ont conduit aux erreurs logicielles. Ces causes nous amènent maintenant, dans une étape ultérieure, à repenser et à adapter certains processus internes, les procédures correspondantes et la documentation des processus. Le travail n'est donc pas encore terminé après l'ACR 😉.

Sources

• SUST 1

• SUST 2

  SUST 3

• SUST 4

• Wikipedia

  NZZ

• SRF

• ZHAW