Développement de logiciels critiques

Introduction au Développement de logiciels critiques

A l’issue de la présentation technique de Jean-Pierre ROSEN, expert en langage Ada, les enseignements de base pour développer un logiciel critique ont été tirés :

Qu’est-ce qu’un logiciel critique ?

Un logiciel est qualifié de « critique » si une panne peut avoir des conséquences graves (mort, accident, dégâts matériels, humains, financiers  ou environnementaux graves).  Les logiciels critiques sont présents dans de nombreux domaines comme l’aviation, le ferroviaire, l’automobile, le nucléaire, le médical et bien d’autres secteurs encore.

Compte tenu des conséquences possibles d’un défaut, les méthodes utilisées dans d’autres domaines qui acceptent un certain taux d’erreur ne sont pas acceptables. C’est pourquoi des standards, des processus, et des méthodes spécifiques aux logiciels critiques ont été développés.

Attention : les contraintes portent sur la sécurité (safety en anglais), et ne doivent pas être confondues avec celles portant sur la sûreté, c’est-à-dire qui concernent la résistance à des attaques malveillantes (security en anglais).

Selon les cas, les exigences en matière de sécurité s’appuieront soit sur le seul risque, soit sur un risque pondéré par sa probabilité, selon ce que l’on appelle une matrice de criticité.

Les fondamentaux du développement d’un logiciel critique

Deux aspects sont fondamentaux pour s’assurer qu’un logiciel exécute correctement la fonctionnalité demandée : d’abord,  s’assurer que l’intention est correcte en définissant clairement les exigences et en les vérifiant selon un processus rigoureux. Ensuite, il faut s’assurer que le code corresponde bien avec l’intention. Ceci demande d’assurer la traçabilité entre le code et la conception, de s’assurer de la lisibilité et de la compréhensibilité du développement , de tester le logiciel par rapport aux exigences, et d’utiliser les outils (vérifications, preuves) fournis par le langage.

Comme pour des véhicules, les mesures de sécurité se répartissent en deux classes :

  • La sécurité active qui permet de prévenir l’accident (typage fort, vérifications et preuves du programme).
  • La sécurité passive qui permet de minimiser les conséquences de l’accident (programmation défensive, traitement d’exceptions, mode dégradé).

Standards et certification

Plusieurs normes portant sur les logiciels critiques ont été mises en place selon le domaine d’application. La plus ancienne concerne les logiciels « aviation », et a servi de base aux autres normes : la fameuse DO-178B/ ED-12B, DO-178C. Dans le domaine ferroviaire, c’est la norme EN-50128 qui s’applique. D’autres standards sont  applicables pour l’automobile, les systèmes militaires et spatiaux, le nucléaire et le médical. Les différentes normes imposent des contraintes différentes pour tenir compte des différences dans les domaines d’application, mais toutes concernent principalement les processus à mettre en œuvre.

Il ne suffit pas que le logiciel soit correct. Il faut être capable de prouver que le logiciel est correct. Tout logiciel critique doit se faire certifier (exigence légale) et le certificateur doit être une organisation indépendante. Le bon déroulement de la certification est la responsabilité de l’équipe de sécurité, qui est, elle, interne à la société conceptrice du logiciel.

L’indépendance doit être garantie entre la conception et le développement du logiciel critique. Elle est également requise entre la vérification et les tests afin de repérer toute faille pouvant porter atteinte à la sécurité du logiciel.

En outre, le certificateur doit avoir l’autorité d’arrêter le projet. Quant aux hauts degrés de criticité, le certificateur ne doit pas dépendre hiérarchiquement du chef de projet.

Tests, et au-delà

Bien entendu, les logiciels doivent être testés. Les tests sont fondés sur les exigences : toute exigence doit être testée, mais réciproquement tout test doit correspondre à une exigence. Selon le niveau de criticité, diverses formes de tests de couverture sont exigés : couverture d’instructions, couverture de décisions, couverture de conditions, MC/DC (Modified Condition/Decision Coverage). Plus la couverture est exigeante, plus le nombre de tests requis (et donc le coût) augmente.

Mais si les tests permettent de montrer que le logiciel fonctionne dans certains cas, ils ne peuvent garantir l’absence de défauts dans tous les cas. L’étape suivante qui se développe actuellement est l’utilisation de techniques de preuve de programme au moyen de langages formels.

Pour en savoir plus, rendez-vous sur :

Nous vous proposons des solutions autour du système d’information, système expert, embarqué et édition de logiciels,  nous permettant de répondre à la plupart des exigences du marché. 

Machine Learning ou Deep Learning ?

Machine Learning ou Deep Learning ?

L’intelligence artificielle est rendue possible par plusieurs concepts. Les deux plus importants sont le Machine Learning en ce qui concerne l’apprentissage automatique et le Deep Learning en ce qui concerne l’apprentissage profond. Bien qu’il s’agisse de deux méthodes différentes, ces deux termes sont souvent confondus.

Qu’est-ce que le machine learning ?

C’est une technologie connue pour son ancienneté et sa simplicité. Cette technologie est déployée par le biais d’un système algorithmique qui s’adapte automatiquement en fonction des retours faits par l’utilisateur. En termes simples, la machine apprend sans programmation. Une condition essentielle pour sa mise en œuvre est l’existence de données organisées. Ensuite, la structuration et la catégorisation des données serviront à alimenter le système. Cela lui permettra d’assimiler la classification de nouvelles données similaires. Sur cette base, le système effectue ensuite des actions.

Petit point sur le deep learning ?

Appartenant à la grande famille de l’apprentissage, le Deep Learning s’appuie sur les technologies de réseaux de neurones pour apprendre des fonctionnalités à un niveau supérieur en utilisant les informations fournies. Les données structurées ne sont pas nécessaires pour ce type d’intelligence artificielle. Inspirées du cerveau humain, il s’agit de neurones artificiels organisés en couches où chaque couche contribue à alimenter la couche suivante et permet d’ajuster le modèle mathématique sous-jacent. Les données non structurées ne sont pas un obstacle à son déploiement. Mais il est clair que le Deep learning doit s’appuyer sur un large volume d’informations/ de situations pour être performant dans la détection des similarités.

Quelle est la différence entre les deux ?

La différence entre ces deux technologies d’intelligence artificielle réside dans les résultats produits par les différents algorithmes et les méthodes d’intervention en aval. La première technologie traite des données quantitatives et structurées. Cependant, les retours de prédictions inexactes nécessitent l’intervention d’un ingénieur pour d’éventuels ajustements. En revanche, la seconde, le modèle Deep Learning, dispose d’algorithmes capables de déterminer l’exactitude d’une prédiction sans intervention humaine. Le Deep Learning est aujourd’hui quasiment incontournable dans la reconnaissance de forme, le traitement du langage naturel (NLP), la construction d’un bot ou encore le diagnostic médical.

Emploi : Quels sont les profils de la Maîtrise du risque en AMOA

Emploi : Quels sont les profils de la Maîtrise du risque en AMOA ?

Les capacités ou compétences suivantes sont nécessaires pour une analyse des risques et une gestion efficace du risque AMOA :

Gestion des incidents AMOA

Il permet de développer un processus en boucle pour l’enregistrement des incidents, en faisant une analyse des risques sur le même qui permet de définir la cause profonde qui l’a provoquée et de pouvoir, sur la base de celle-ci, définir les actions opportunes avec lesquelles lui donner un traitement.

La gestion des incidents est un processus réactif, mais elle est d’une grande utilité pour les organisations, car elle leur permet de tirer des enseignements des problèmes et des conflits survenus afin de prendre les mesures qu’elles jugent appropriées pour les prévenir.

Il s’agit donc d’une capacité essentielle dans la gestion du risque opérationnel et elle s’applique principalement aux risques liés à des événements.

Gestion du changement

Comme mentionné précédemment, lorsque des changements sont introduits dans n’importe quel aspect des opérations, il est courant que de nouvelles sources de risque apparaissent et puissent générer des incidents. En ce sens, en appliquant un processus de gestion du changement approprié, nous contribuons à ce que le personnel puisse identifier, évaluer et approuver systématiquement les modifications à introduire avant de les rendre effectives.

La gestion du changement s’applique généralement aux risques motivés par le changement.

Évaluation des risques

Cette compétence implique la réalisation d’un processus permettant d’identifier les dangers dans les différentes opérations, afin de procéder à l’analyse appropriée en vue de les hiérarchiser pour pouvoir appliquer les contrôles pertinents et les surveiller efficacement.

Ce processus d’évaluation des risques est proactif afin de parvenir à une amélioration continue et est appliqué dans les évaluations réalisées pour améliorer les installations, les systèmes de production ou les zones de travail, afin d’atténuer tout risque opérationnel éventuel.

Cette troisième compétence peut être appliquée à tous les types de risques, qu’ils soient liés à la performance, aux événements ou aux changements.

Le BRMS (moteur de règles) : toujours un avenir ?

Le BRMS (moteur de règles) : toujours un avenir ?

A l’heure où l’Intelligence Artificielle est devenue LE sujet, l’incontournable atout dans les systèmes d’informations, le moteur de règles ou BRMS (technologie créée dans les années 70 et composante intégrante de l’IA) n’est pratiquement plus enseigné dans les écoles d’ingénieurs. Et pourtant, cette technologie est encore très activement utilisée dans tous les secteurs.

Deep Learning vs Expertise humaine métier

Quand on vous parle d’Intelligence artificielle, immédiatement vient à l’esprit le Machine Learning et le Deep Learning, ces algorithmes permettant un apprentissage par la machine d’un raisonnement à appliquer dans des situations similaires à celles sur lesquelles la machine s’est entrainée. Mais chaque entreprise est dotée d’une expertise métier humaine très riche, capable d’analyser et de construire une prise de décision adaptée à chaque cas rencontré. Pourquoi alors ne pas mettre pleinement à profit cette expertise en dotant les experts métiers de solutions informatiques leur permettant de transposer leur raisonnement ? Le moteur de règles est une solution.

Particulariser plutôt que catégoriser

Dans ce flot d’information qui nous inonde chaque jour, nous nous devons de faire le filtre, le tri pour porter notre intérêt sur ce qui nous paraît crédible et donc de confiance. La dématérialisation du contact et la numérisation de l’information n’empêchent pas le conseil pertinent et approprié. Aujourd’hui, qu’on le veuille ou non, des intelligences artificielles s’activent de plus en plus pour apprendre sur vous, votre comportement, vos préférences etc… Simplement, cet apprentissage ne conduit pas systématiquement à une réponse ou offre pertinente, adaptée à votre cas particulier, et en parfaite adéquation avec la stratégie des entreprises qui souhaitent vous « cerner ». L’intelligence de la statistique et de l’apprentissage n’exclut pas l’erreur de catégorisation. C’est là qu’intervient le BRMS !

Du système expert au BRMS

Il y a 40 ans, on commençait à modéliser le principe du diagnostic d’une pathologie à partir de symptômes cliniques ; c’était le début des systèmes experts qui, par instinct de survie et à coup de repackaging marketing au milieu des années 90, deviendront des Business Rules Management Systems (BRMS) 30 ans plus tard. Ce qui paraissait être de l’arrogance intellectuelle et scientifique est devenu une réponse au dialogue personnalisé et à la capitalisation de l’expertise. Aujourd’hui, le BRMS demeure une inférence cognitive présente dans tous les secteurs d’activité. La quasi-totalité des institutions financières françaises utilisent un moteur de règles pour leur processus d’octroi de crédit, notamment dans l’analyse du risque. Le secteur industriel comme financier et assurantiel ont mis en place des processus de tarification pilotés par les moteurs de règles, qui sont également une réponse dans les systèmes de détection de fraude et de lutte contre le blanchiment d’argent …

Les moteurs de règles (BRMS) ont encore un bel avenir !