J'ai assisté ce mercredi à une journée d'étude sur le thème "agilité et logiciels sûrs". Organisé par Aerospace Valley, il y avait une quarantaine de personnes, à la fois des agilistes expérimentés et des curieux, voir dubitatifs, pour l'essentiel venant des industriels du secteur.

https://www.logilab.org/file/1625539?vid=download

C'est Claude Aubry qui s'est chargé de chauffer la salle en posant les fondements de l'agilité en général et de Scrum en particulier. Je ne vais pas m'étendre sur cette présentation rapide, efficace et appréciée, si ce n'est sur les rappels suivants qui me paraissent particulièrement intéressants dans le contexte :

  • l'agilité est une culture avant d'être des processus,
  • cela permet de gérer le décalage entre les plans et la réalité grâce à une boucle de rétroaction courte,
  • c'est fait pour gérer des systèmes complexes et adaptatifs,
  • dans le cadre du développement de logiciel sûr, on prendra notamment soin à :
    • la présence d'experts lors des réunions d'affinage,
    • la définition de fini,
    • montrer l'incertitude.

Je citerai pour conclure cette introduction la définition de l'Agilité selon Claude :

"l'agilité est la capacité d'une organisation à fournir tôt et souvent de la valeur, tout en s'adaptant à temps aux changements dans son environnement"
https://upload.wikimedia.org/wikipedia/commons/1/1a/ST_vs_Gloucester_-_Match_-_23.JPG

(photo par Pierre Selim, licence CC-By-SA 3.0)

Gérard Ladier et Jean-Paul Blanquart sont ensuite entrés dans le vif du sujet avec une double-présentation-avec-passe-de-ballon (oui oui, y avait 2 projections simultanées avec 2 projecteurs) sur le sujet des contraintes liées au besoin de certification dans le cadre de l'aéronautique pour Gérard et du spatial pour Jean-Paul.

En commençant par rappeler que normes et règlements ne sont pas là (que) pour nous embêter mais avant tout pour protéger des parties prenantes qui n'ont pas forcément leur mot à dire dans le cadre de la définition d'un produit. Comme vous et moi dans le cadre d'un nouvel avion par exemple : on nous demande pas notre avis mais on pourrait bien finir par le prendre. Ainsi, ces normes et règlements sont censés fournir un cadre permettant de répondre à un objectif de très haut niveau, aussi simple que "on ne doit pas risquer sa vie en montant dans un avion de ligne".

Je vais passer sur la plupart des points techniques, si ce n'est pour citer la fameuse DO-178C aéronautique qui est la norme définissant les différents niveaux de conformité qu'un logiciel devra agréer dans le cadre de la certification d'un programme. Apparemment, s'il y en a bien une à connaître c'est celle-ci (et ECSS côté spatial).

Le point important, c'est que ces normes découpent le projet en phase avec des échéances obligatoires mais sans pour autant y associer de méthode. Notamment le cycle de développement en soi n'est pas normé. Il n'y a donc pas de contre-indications à utiliser des méthodes agiles pour répondre aux exigences de ces normes. Ce qui ne veut pas dire qu'il n'y a pas de résistance au changement des habitudes, et notamment celles des experts...

Gérard a complété ce numéro de duettistes par une présentation des attentes d'Airbus en manière d'agilité :

  1. changer la manière de développer pour accompagner le passage à un mode de développement incrémental des avions et obtenir une diminution du time-to-market,
  2. diminuer les coûts liés aux défauts pour permettre l'augmentation des taux de productions,
  3. améliorer la gestion du risque et de la complexité afin de faire face à l'augmentation des coût de développement

Donc si on en croit cette présentation, Airbus constate qu'il faut apprendre à travailler différemment, ils sont prêts à tester l'agilité sur des sous-systèmes (trop disruptif sur un système complet, faut pas pousser !) et sont même en attente de challenges de la part de leur partenaires. À suivre !

https://www.logilab.org/file/1616201?vid=download

(photo par pixabay, licence CC0)

L'après-midi, on est reparti sur les chapeaux de roue avec une présentation d'Emmanuel Chenu de Thales Avionics, porteur d'un message massue : "on l'a fait (et on en est content)". Tout part du constat des problèmes liés à l'intégration "big-bang" entre logiciels ou entre logiciel et matériel, mais aussi du fait que mener les activités liées à la certification tardivement et en gros lots :

  • ne réduit pas la complexité,
  • ne permet pas de corriger tôt les pratiques,
  • génère des activités peu efficaces et pas fiables,
  • empire avec l'avancée dans le projet.

Ces choix ne sont évidemment pas un hasard, ils s'expliquent en particulier par le besoin de versions anticipées non certifiées, ou encore par les échéances des audits qui collent au cycle en V. Malgré tout cela, ils ont donc tenté d'appliquer l'agilité aux développements d'une centrale inertielle pour l'A350 (ADIRU de son petit nom). Ce projet, qui doit répondre au plus haut niveau de la norme DO-178C, est spécifié par plusieurs milliers d'exigences et est constitué au final de plus de 500 000 lignes de code spécifiques. Et il semblerait qu'à l'issue du projet, tout le monde était content :

  • l'avionneur, car il a eu plusieurs livraisons intermédiaires sans régressions et avec globalement moins de défauts (environ 0.15 / kLOC, soit un facteur 100 par rapport aux taux habituels d'après Emmanuel),
  • le service qualité, car il a des retours rapides, globalement moins de soucis et qu'il apprécie la motivation de l'équipe, à la fois à développer et à améliorer son process,
  • l'autorité de certification, qui a été impressionné par le respect des exigences du produit.

Et vu le deuxième point, on peut raisonnablement penser que l'équipe Thales était contente aussi !

Les enseignements tirés par Thales et identifiés comme des savoir-faire critiques sont :

  • "produit potentiellement livrable" = le logiciel accompagné de tous les artefacts qui vont avec (notamment ceux nécessaires pour la certification des features développées),
  • l'importance en premier lieu des pratiques techniques:
    • architecture objet
    • test de couverture automatisés
    • intégration continue
    • safe delivery
    • stop the line
    • design by contract
    • qualimétrie
  • il est indispensable d'avoir une gestion de configuration très rigoureuse, notamment en utilisant du versionnement pour les exigences comme pour le code,
  • il faut réorganiser les revues pour ne pas coller au cycle en V, et décrire les itérations et incréments dans les plans.

Évidemment, comme toujours en développement agile mais encore plus ici : la qualité n'est pas une variable d'ajustement. Et le processus dans son ensemble est suivi par un certain nombre d'indicateurs dont :

  • une mesure "qualité" sur le long terme (somme de critères évolutifs),
  • la couverture des tests,
  • le nombre d'exigences satisfaites.

Au final, l'avionneur peut s'appuyer sur les versions intermédiaires pour développer d'autres parties de manière incrémentale, il a une mesure plus objective de l'avancement et il obtient une baisse significative des défauts résiduels et de l'impact des changements de priorité. Surtout, Thales démontre ici que l'agilité et la certification DO-178C ne sont pas incompatibles, bien au contraire.

https://upload.wikimedia.org/wikipedia/commons/thumb/8/8c/Airbus_A350-900_XWB_Airbus_Industries_%28AIB%29_MSN_001_-_F-WXWB_%2810223175703%29.jpg/640px-Airbus_A350-900_XWB_Airbus_Industries_%28AIB%29_MSN_001_-_F-WXWB_%2810223175703%29.jpg

(photo par Laurent Errera, licence CC-By-SA 2.0)

La dernière présentation de l'après-midi était celle de Vincent Meunier (SII), mais je dois avouer que mon attention était déjà sévèrement entamée et que le fait qu'il y ait pas mal de recouvrement avec les présentations précédentes l'a achevée. Je me contenterai donc des points suivants que j'ai relevés :

  • il faut coopérer avec tout le monde, y compris les autorités,
  • ne surtout pas retarder les éléments risqués,
  • tester dans un sprint les processus ou les outils dont on doute,
  • adapter le processus global,
  • laisser l'équipe suggérer les améliorations.

L'après-midi s'est terminée par une séance de brainstorming autour des points à améliorer ou des actions à mener afin d'étendre l'usage de l'agilité dans le contexte de logiciels sûrs. De nombreuses idées ont été soulevés par l'ensemble de l'audience, visiblement intéressée par le sujet. Au point que le pôle Aerospace Valley semble prêt à creuser encore le sujet via un groupe de discussion.

J'ai de mon côté été agréablement surpris de ce que j'ai vu et entendu. Arrivant avec un a priori négatif sur la relation du milieu l'aéronautique (et en particulier d'Airbus) vis-à-vis de l'agilité, cette journée me fait penser que c'est possible, au moins localement ! Quant au temps qu'il faudra pour faire bouger les lignes, l'avenir nous le dira - mais ça va être long.

En tout cas merci à Aerospace Valley et en particulier à Gérard Ladier pour cette journée, ainsi qu'à l'ensemble des intervenants qui étaient tous de grande qualité.

blog entry of