10 règles d’or pour créer un lancement sans bugs !

La NASA est mondialement connue pour ses missions spatiales, mais elle est également à l'avant-garde des pratiques de développement de logiciels critiques pour la sécurité.

Depuis 2006, le Jet Propulsion Laboratory (JPL) de la NASA a mis en place un ensemble de directives de codage, connues sous le nom de "Power of 10", pour garantir la sûreté et la fiabilité des logiciels embarqués dans leurs missions.

Ces règles, développées par le Laboratoire pour les logiciels fiables du JPL, sont destinées à éliminer les pratiques de codage en C qui compliquent la révision et l'analyse correcte du code avec des outils d'analyse statique.

Les directives de la NASA sont conçues pour améliorer la testabilité, la lisibilité et la fiabilité du code, des aspects cruciaux lorsqu'il s'agit de logiciels déployés dans l'environnement extrême de l'espace. Les erreurs dans ces contextes peuvent avoir des conséquences catastrophiques, d'où l'importance de suivre des normes de codage strictes dès le début du développement.

Le "Power of 10" repose sur une idée simple : simplifier le code autant que possible pour réduire les risques d'erreurs. Voici un aperçu des dix règles que la NASA applique pour développer des logiciels critiques pour la sécurité :

• Limiter le flux de contrôle à des constructions simples : éviter les déclarations “goto” (exécuter un bout de code ailleurs dans le fichier), “setjmp” et “longjmp” (aller chercher une valeur et/ ou la conserver pour l'exécuter dans un ordre défini) et la récursion directe ou indirecte.

• Fixer une limite supérieure pour toutes les boucles : assurer que toutes les boucles aient un nombre d'itérations déterminé pour ne pas trop remplir le cache mémoire.

• Éviter l'allocation dynamique de mémoire après l'initialisation : réduire les risques liés à la gestion de la mémoire dynamique en limitant son utilisation.

• Limiter la longueur des fonctions : une fonction ne doit pas dépasser ce qui peut être imprimé sur une seule feuille de papier dans un format standard, avec une ligne par déclaration.

• Maintenir une densité minimale d'assertions : chaque fonction doit contenir au moins deux assertions pour vérifier les conditions (pour vérifier une variable).

• Déclarer les objets de données au niveau de portée le plus restreint possible : minimiser la portée des variables pour réduire les interactions inattendues.

• Vérifier les valeurs de retour des fonctions non void : Chaque fonction appelante doit vérifier la valeur de retour et chaque fonction appelée doit valider les paramètres reçus.

• Limiter l'utilisation du préprocesseur : se limiter à l'inclusion de fichiers d'en-tête et à des définitions de macros simples.

• Limiter l'utilisation des pointeurs : utiliser les pointeurs de manière restreinte, en évitant les pointeurs de fonction et les déréréférencements multiples.

• Compiler avec tous les avertissements activés : corriger tous les avertissements avant de publier le logiciel.

Même si ces règles peuvent paraitre barbare, voire incompréhensible si vous ne touchez pas à la programmation, il faut se rendre compte d’une chose : les programmeurs de la NASA cherchent toujours à créer le code le plus simple possible, en faisant en sorte que chaque fonction du code soit utilisé à des fins très précises pour ne pas rencontrer d’erreurs au mauvais moment.

Ces règles ont été développées pour les missions spatiales de la NASA, mais techniquement, elles sont accessibles et applicables à tous les développeurs de logiciels.

La simplicité de ces règles, qui pourrait être comparée à l'approche intuitive qu'un enfant adopterait, en fait un cadre efficace pour la programmation sécurisée. La clé de leur succès réside dans leur capacité à réduire la complexité du code, rendant les erreurs plus faciles à détecter et à corriger.

Une petite erreur peut être critique pour la NASA

Les règles de codage "Power of 10" de la NASA offrent une méthode éprouvée et accessible pour développer des logiciels sûrs et fiables. En adoptant ces pratiques, les développeurs peuvent créer des systèmes plus robustes, minimisant les erreurs et maximisant la sécurité, tout comme la NASA le fait pour ses missions dans l'espace. Ces principes, bien que simples, sont puissants et démontrent que parfois, "il suffit de faire comme un enfant le ferait" pour atteindre l'excellence en matière de développement de logiciels.

Lanceur SpaceX

Imaginez si un lanceur décolle, et que l’on se rend compte que l’une des fonctions du logiciel de lancement ne parvient pas à atteindre les fichiers qu’il faudrait pour garantir un lancement réussi. La vie d’astronautes pourrait être en danger, et même dans un cas moins grave, énormément d'investissements pourraient être perdus en un claquement de doigts.

Pour mettre en œuvre ces règles dans le développement quotidien, les développeurs peuvent utiliser des outils d'analyse statique de code. Ces outils sont conçus pour appliquer automatiquement les directives de la NASA, en vérifiant le code contre des taxonomies de qualité et en signalant les violations des normes. L'analyse statique permet de repérer les problèmes potentiels avant même que le code ne soit exécuté, ce qui est essentiel pour garantir la sécurité des applications critiques.

L'utilisation d'outils d'analyse statique ne se limite pas à la conformité aux règles de la NASA. Elle s'étend également à d'autres normes de sécurité fonctionnelle, telles que IEC 61508 et EN 50128, qui sont cruciales dans des industries comme l'automobile, le ferroviaire et l'aéronautique. En appliquant ces règles simples mais efficaces, les développeurs peuvent améliorer la qualité et la fiabilité de leurs logiciels, réduisant ainsi les risques et les coûts associés aux erreurs de programmation.

Une méthode “assez intuitive” au final puisqu’elle cherche à simplifier au maximum la complexité d’un code faisant appel à autant de données et de fonctions.