L’audit et la certification des algorithmes

 Par Claude Salzman

  

Pendant longtemps on a utilisé des algorithmes sans se poser trop de questions. Ils permettaient, par exemple, d’effectuer des tris, de crypter des données, de gérer des communications, … Seuls les spécialistes s’intéressaient à leur contenu. Les ordinateurs étaient en ce temps-là peu puissants. Le principal objectif était d’optimiser leur code de façon à améliorer leur fonctionnement.

Or, depuis quelques années, on constate qu’un nouvel objectif est apparu : il consiste à s’assurer du contenu des algorithmes. Cette préoccupation est due à une montée des inquiétudes envers ceux-ci car on craint que des choses importantes seraient cachés à leurs utilisateurs.

Ce type de préoccupation est très clairement apparu lorsque les dysfonctionnements d’APB (Admission Post Bac) et de sa nouvelle version Parcoursup ont été constatés. Le développement de l’Intelligence Artificielle et notamment le Deep Learning ne peut que renforcer la suspicion à l’encontre des algorithmes car on ne sait plus très bien ce qu’ils font ([1]) ? Que se passera-t-il si les ordinateurs devenaient plus intelligents que les hommes ? Est-ce qu’ils prendraient le pouvoir et mettraient les hommes en esclavage ? Et que se passerait-il si les robots se reprogrammait d’eux-mêmes ? …. Ainsi on assiste à une libération de tous les fantasmes possibles et imaginables. C’est la Grande Peur des Algorithmes. 

Cédric Villani saisi par le doute

Dans son récent rapport : « Donner un sens à l’Intelligence Artificielle » le mathématicien-député Cédric Villani montre l’importance du développement de la recherche dans ce domaine stratégique. Avec le talent et le brio qu’on lui connait il a démontré en 234 pages l’impérieuse nécessité d’investir dans la recherche en intelligence artificielle notamment dans quatre secteurs stratégiques : la santé, les transports-mobilités, l’environnement et la défense-sécurité. Après de nombreuses analyses et des recommandations intéressantes afin de concentrer les moyens et les rendre plus efficaces on trouve une 5^ème partie un peu plus étonnante : « Quelle éthique de l’IA ? ».

 

Rapport sur l'Intelligence Artificielle de Cédric Villani

 Chapitre 5 Quelle éthique à l'IA

Cédric Villani part d’une constatation : « Ces dernières années de nombreuses voix se sont interrogées sur la capacité de l’IA à réellement œuvrer à notre bien-être et sur les dispositions à prendre pour s’assurer que cela soit le cas ». Est-ce qu’on a eu ce type de préoccupation lorsque James Watt a inventé la machine à vapeur ou au moment où Jules de Dion et Georges Bouton ont fabriqué la première voiture à essence ?

Cédric Villani précise que « les réflexions se sont cristallisées autour des algorithmes du quotidien. …. Car nous ne sommes pas tous égaux devant ces algorithmes et que leur partialité a des conséquences réelles sur nos vies ». Reconnaissons que c’est une curieuse manière d’aborder la question.

En conséquence à la page suivante Cédric Villani propose : « d'accroître la transparence et l’auditabilité des systèmes autonomes … en développant les capacités nécessaires pour observer, comprendre et auditer leur fonctionnement ». Pour cela il suggère de développer l’audit des applications d’Intelligence Artificielle en créant «  un corps d’experts dotés des compétences requises … pour procéder à des tests par tout moyen requis ». C’est bien. En fait Cédric Villani réinvente le métier de l’audit et la profession d’auditeur informatique.

Une affaire de bonnes pratiques

Pour auditer des algorithmes, quels qu’ils soient, il est d’abord nécessaire de se demander s’ils sont auditables. De nombreux sont ceux qui pensent que s’ils recourent à l’intelligence artificielle il serait difficile, voire même impossible de les auditer.

Premier constat : COBIT, le référentiel des auditeurs informatiques, ne dit rien des algorithmes. Autant il est précis et détaillé en ce qui concerne les programmes de développement et les projets autant on note qu’il ne dit rien sur les algorithmes. Cependant, comme nous le verrons plus loin, les nombreuses bonnes pratiques mises en avant pour les projets et les applications s’appliquent sans trop d’adaptation aux algorithmes comme :

·       Avoir un document de conception,

·       Disposer d’un pilotage efficace de la réalisation.

·       S’assurer que des tests suffisants ont été mis en œuvre.

·       Disposer d’une procédure validation de l’algorithme avant sa mise en production.

·       Garantir une évolution sécurisée de l’application,

·       ……

Ces bonnes pratiques sont bien connues et généralement appliquées. A partir du moment où elles existent et sont généralement reconnues il est possible d’auditer les algorithmes en se basant sur ces bonnes pratiques. Les algorithmes d’intelligence artificielle, comme les autres algorithmes, respectent ces bonnes pratiques même s’ils se basent sur des techniques particulières comme le deep learning. Ils sont donc auditables.

Une fois que des bonnes pratiques sont identifiées il est nécessaire de définir les objectifs de contrôle puis d’identifier de manière précise les points de contrôle qui seraient audités. Ce n’est pas simple car on peut, sans s’en rendre compte, s’embarquer dans des opérations lourdes et complexes comme, par exemple, de vouloir tester tous les cas possibles ou d’analyser le code pour s’assurer qu’il est conforme. Dans ces conditions comment s’assurer de la qualité de la conception ? Faut-il exiger une documentation complète de chaque algorithme ? Que faire quand le fournisseur ne livre que le code exécutable et non le code source ? …. Il est pour cela important de choisir des points de contrôle facile à vérifier.

Faire face à une grande variété d’algorithmes

Cédric Villani n’évoque dans son rapport que les algorithmes recourant à l’intelligence artificielle mais à côté de ceux-ci il existe une grande variété d’algorithmes. Certain sont simples alors que d’autres sont d’une très grande complexité. Il n’existe pas de recensement tous les algorithmes et encore moins une nomenclature « officielle » des algorithmes. Les auteurs de Wikipédia ont essayé de les recenser et de les classer. Il est assez significatif de constater que la version française et la version anglaise sont différentes (cliquez ici pour la version en français, https://fr.wikipedia.org/wiki/Liste_d%27algorithmes, et cliquez là pour la version en anglais, https://en.wikipedia.org/wiki/List_of_algorithms ). La liste française fait 4 pages alors que celle en anglais fait 21 pages ! En vérité il existe des milliers ou des dizaines de milliers d’algorithmes.

Pour avancer je propose de classer des algorithmes en 7 grandes classes. Voir le détail du classement dans l’annexe 1 ci-dessous :

1.     Routines de calcul 

2.     Communication

3.     Système d’exploitation

4.     Gestion des données

5.     Gestion de texte 

6.     Optimisation

7.     Intelligence Artificielle

Comme on le montre les détails donnés en annexe 1 voit les algorithmes sont très variés. Parmi ceux-ci les algorithmes d’intelligence artificielle ne représentent qu’une partie des algorithmes existants. Ils doivent pouvoir être audités comme peuvent l’être les autres algorithmes.

Les bonnes pratiques existent en matière d’algorithmes

Le développement des algorithmes est toujours un processus complexe s’étendant dans le temps et faisant intervenir de nombreux intervenants. Très fréquemment de nombreux ajustements sont effectués au cours du processus.

L’expérience a permis de dégager quelques bonnes pratiques. Sans chercher à être exhaustif il est possible de mettre en avant les plus importants Voir le détail des bonnes pratiques dans l’annexe 2 ci-dessous :

1.     Nécessité d’une conception.

2.     Documentation suffisante.

3.     Effectuer des tests suffisants.

4.     Disposer d’un environnement de tests avec des données de tests.

5.     Conformité de l’algorithme aux spécifications faites par les professionnels.

6.     Satisfaction des utilisateurs.

Bien entendu il existe d’autres bonnes pratiques en matière d’algorithme mais les six règles ci-dessus représentent l’essentiel des points clés.

Objectifs de contrôle des algorithmes

Sur la base de ces six bonnes pratiques il est possible d’identifier un certain nombre d’objectifs de contrôle. Voir le détail de la liste des objectifs de contrôle dans l’annexe 3 ci-dessous :

1.     Des spécifications claires et compréhensibles.

2.     Conformité de l’algorithme à ses spécifications.

3.     Suivre les interventions de maintenance.

4.     Existence d’un jeu d’essais.

5.     Tester et réceptionner l’algorithme.

6.     Tester ensuite périodiquement l’algorithme.

7.     Le programme exploité est effectivement l’algorithme audité.

Ces objectifs de contrôle permettent d’auditer tout algorithme quelque soit sa fonction, son langage, sa complexité…. Ceci montre qu’il sera difficile de porter un jugement sur un algorithme si on ne dispose pas d’un document décrivant les fonctions de l’algorithme, de jeux d’essais, d’un environnement de test opérationnel, d’un historique des interventions effectuées, …

Les points de contrôle des algorithmes

Sur la base de ces objectifs de contrôle identifiés il est possible de dégager un certain nombre de points de contrôle permettant à l’auditeur d’évaluer un algorithme donné. L’ordre de mission de l’audit doit détailler le ou les algorithmes à auditer et les questions auxquelles l’auditeur doit répondre Avant de commencer sa mission l’auditeur va s’assurer qu’ils correspondent à des points de contrôle.

Il est de plus nécessaire de s’assurer que les principaux algorithmes de l’application sont bien identifiés et notamment ceux posant problèmes selon les dires des demandeurs d’audit. Il est enfin utile que ce document soit validé par un organe de concertation type comité de pilotage.

Voir le détail de la liste des points de contrôles dans l’annexe 4 ci-dessous :

1.     Existence d’une note de cadrage.

2.     Le périmètre et le contenu fonctionnel de chaque algorithme doivent être clairement défini.

3.     La liste des fonctions mise en œuvre par l’algorithme.

4.     Un schéma explique le fonctionnement de l’algorithme.

5.     Existence d’un recensement des exceptions et des cas particuliers.

6.     Analyse des spécifications de l’algorithme et de leur exécution effective.

7.     Conformité de ou des algorithmes.

8.     Evolution fonctionnelle de l’application par rapport aux spécifications d’origine.

9.     Existence d’un jeu d’essais.

10.  Existence d’un procès-verbal de réception.

11.  Existence de tests de charge.

12.  Exécution du jeu d’essais.

13.  Mode d’exécution des tests.

14.  Études des anomalies constatées.

15.  Analyse des informations données aux utilisateurs.

16.  Messages d’erreurs.

17.  Opinion des utilisateurs.

18.  Remontée des utilisateurs.

19.  Tableau de bord de l’algorithme.

20.  Détection de substitution.

Bien entendu il existe de nombreux autres points de contrôles possibles mais ceux-ci couvrent l’essentiel de ceux nécessaire pour effectuer un audit d’algorithme. Ils ont deux avantages :il sont simples à comprendre et assez facile à évaluer (pour plus de détail des points de contrôle voir l’annexes 4 ci-dessous).

Vers la certification

Au-delà de l’audit des algorithmes il est possible d’envisager leur certification. C’est une démarche voisine mais nettement plus exigeante. « La certification est l'attestation par une tierce partie qu'un produit, processus ou système répond à toutes les exigences du programme de certification. Ces exigences sont répertoriées dans un document appelé schéma de certification. Les programmes de certification CEI 61508 sont gérés par des organisations tierces impartiales appelées Organismes de certification (OC). Ces organismes de certification sont accrédités pour fonctionner conformément à d’autres normes internationales, notamment ISO / IEC 17065 et ISO / IEC 17025. Les organismes de certification sont accrédités pour effectuer les travaux d’audit, d’évaluation et de test par un organisme d’accréditation (AB) » ([2]). Comme on le voit, c’est une démarche assez proche de l’audit sauf que les exigences sont clairement identifiées par une norme et appliquées par un organisme de certification accrédité par un organisme d’accréditation.

La certification de logiciels n’est pas une démarche nouvelle. Elle existe depuis près de 40 ans notamment pour l’aviation (norme DO 178C notamment pour les pilotes automatiques) mais aussi pour des secteurs comme le ferroviaire (norme EN 50128), le nucléaire (norme IEC 60880), l’automobile (ISO 26262) et plus généralement tous les systèmes industriels faisant appel à l’électronique et aux systèmes informatiques (IEC/CEI 61508). Ces démarches sont basées sur une évaluation des risques induits par l’usage des logiciels. Pour cela on va s’efforcer d’évaluer les conséquences des défaillances et leur probabilité d’occurrence et ainsi déterminer le ou les points de contrôle.

Pendant longtemps la certification ne concernait que les logiciels et les systèmes à enjeux vitaux comme les pilotes automatiques des avions ou la signalisation des trains. Aujourd’hui on s’intéresse de plus en plus à la certification des applications notamment celles recourant à l’intelligence artificielle. Ceci est probablement dû à la crainte de l’effet boîte noire : que se passe-t-il dans l’application ? N’y a-t-il pas des fonctions cachées ou des paramétrages mystérieux. Les aléas qu’ont connues les applications comme APB et Parcoursup gérant les inscriptions à l’Université expliquent en grande partie la forte sensibilité à ces sujets ([3]). 

La démarche de certification repose sur un quatrain résumant des principes simples qui fondent la démarche qualité :

·       Dire ce que l’on va faire

·       Faire ce qu’on a dit

·       S’assurer qu’on fait bien ce qu’on a dit de faire

·       Rendre compte de ce qu’on a fait

Comme on le voit c’est un domaine vaste et complexe qui mérite un autre post.

Annexe 1 - Classement des algorithmes en 7 classes :

1.     Routines de calcul : ils comprennent les opérations élémentaires (addition, multiplication, …), les fonctions trigonométrie, les différentes formules statistiques, les traitements d’image et du son et notamment leur compactage, la synthèse d’image, le fonctionnement du GPS, le cryptage et le décryptage, la méthode de Monte-Carlo, les transformées de Fourier, ...

2.     Communication : ce sont tous les protocoles d’échange de données allant des plus anciens comme le start-stop, le BSC, X25,… jusqu’au plus utilisés comme TCP/IP, HTTP, SMTP, HTLM, FTP, SNMP, ….

3.     Système d’exploitation et notamment la gestion de la mémoire, l’ordonnancement des tâches, le multitâche, l’interface graphique, les communications inter-processus, les contrôle d’accès, …....

4.     Gestion des données : la gestion du système disque, le séquentiel et le séquentiel indexé, les tris mémoire et les tris disque, les bases de données hiérarchiques et relationnelles et notamment les bases de données réparties type Hadoop, HFS, ...

5.     Gestion de texte : les éditeurs et les programme de traitement de texte, les logiciels de traduction, le contrôle de l’orthographe, ….

6.     Optimisation : ce sont des algorithmes sophistiqués comme celui du voyageur de commerce, celui du sac à dos, l’algorithme Gale-Shapley, la gestion de graphique, l’algorithme de Newton, ...

7.     Intelligence Artificielle : comme la reconnaissance de forme ou de la parole, les réseaux neuronaux, le deep learning, les algorithmes génétiques, ….

Annexe 2 – Liste des bonnes pratiques concernant les algorithmes

1.     Nécessité d’une conception. Un algorithme efficace nécessite de consacrer du temps à réfléchir à ce qu’il devrait faire. Il ne s’agit pas de recenser avec un grand niveau de détail ([4]) toutes les fonctions mais de décrire son périmètre fonctionnel et d’identifier les principales entrées et sorties. Généralement cela se traduit par un document de spécifications. Il est souvent rédigé par les professionnels concernés : futurs utilisateurs ou experts du domaine.

2.     Documentation suffisante. Pour que les utilisateurs puissent mettre en œuvre l’algorithme de manière efficace il est souhaitable de fournir une documentation suffisante. De même, pour qu’il puisse être maintenu dans de bonnes conditions, il est nécessaire de disposer d’une documentation technique suffisante ([5]).

3.     Effectuer des tests suffisants. En cours de la phase de réalisation les développeurs doivent pouvoir tester les fonctions déjà programmées même si le développement de l’algorithme n’est pas terminé. A la fin du développement il est nécessaire de mettre en œuvre une procédure de réception avec une phase de tests techniques puis une étape de contrôle fonctionnels. Au cours de la procédure de réception on doit établir une liste des réserves qui seront ensuite corrigées. Lors des opérations de maintenance ultérieure l’algorithme doit être testé après chaque intervention.

4.     Disposer d’un environnement de tests avec des données de tests. Il est pour cela nécessaire de disposer d’outils efficaces. Ils sont de plus en plus souvent liés aux environnements de développement notamment aux langages (interpréteur ou compilateur). Malheureusement on constate souvent que ces outils ont des caractéristiques limitées. Il est de plus nécessaire d’avoir des bases de données rechargeables ([6]) et les résultats des tests préenregistrés afin de pouvoir constater automatiquement d’éventuels écarts.

5.     Conformité de l’algorithme aux spécifications faites par les professionnels. C’est une étape clé de la procédure de réception. Ils doivent pouvoir s’assurer que l’algorithme effectue correctement les fonctions qu’ils ont demandées et produisent bien les résultats attendus. Il est aussi souhaitable de s’assurer des performances de l’algorithme et notamment d’évaluer sa capacité de résistance à la charge.

6.     Satisfaction des utilisateurs. Il faut s’assurer que l’algorithme répond toujours aux attentes. Or, un traitement donné peut parfaitement satisfaire une partie des utilisateurs et être rejeté, pour de bonnes raisons, par une autre partie. De plus les usages évoluent dans le temps, les volumes à traiter augmentent, les règles mises en œuvre changent, … Il est dans ces conditions important de s’assurer qu’il répond toujours aux attentes.

Annexe 3 - Liste des objectifs de contrôle concernant les algorithmes

1.     Des spécifications claires et compréhensibles. Si le travail d’élaboration a été bâclé où même a été ignoré il ne faut pas s’étonner du résultat. Comme les textes peuvent être ambigus il est souhaitable de les illustrer par un ou des exemples. L’objectif de la démarche est d’éviter les situations de spécifications évolutives au fur et à mesure de l’avancement des développements car elles peuvent amener des dérives importantes.  

2.     Conformité de l’algorithme à ses spécifications. Plus le temps passe plus il est possible qu’un écart significatif apparaisse entre les spécifications d’origine et l’état actuel de l’algorithme. Une documentation suffisante doit permettre de justifier cet écart.

3.     Suivre les interventions de maintenance. Tous les changements apportés au code au cours des opérations de maintenance doivent être enregistrées que ce soit la correction d’anomalies ou des ajouts fonctionnels.

4.     Existence d’un jeu d’essais. Il est souhaitable qu’il y ait des jeux d’essais et un environnement de développement permettant de tester l’algorithme et de s’assurer que les résultats obtenus sont conformes à ce qui était prévu. On doit notamment s’assurer que l’environnement de développement et de tests permet d’exécuter automatiquement et à tout moment les jeux d’essais.

5.     Tester et réceptionner l’algorithme. A la fin du développement il est nécessaire de le tester à l’aide d’un jeu d’essais définis par les futurs 33utilisateurs. Lors de la réception des réserves peuvent être faites et elles doivent être levés avant la réception définitive.

6.     Tester ensuite périodiquement l’algorithme. L’objectif des tests est de détecter d’éventuelles dérives. Effectivement un programme évolue dans le temps au grès des maintenances successives mais aussi des changements de l’environnement (système d’exploitation, langage, routines de communication,  ….). Il est dans ces conditions nécessaire de s’assurer que l’algorithme s’exécute conformément à ce qui était prévu à l’origine. 

7.     Le programme exploité est effectivement l’algorithme audité. Il est nécessaire de s’assurer qu’il n’y a pas eu substitution de code ou dérivation vers un autre code comme cela été le cas dans le « dieselgate ». Dès que le code est volumineux ou touffu ce contrôle peut devenir délicat à mettre en œuvre.

Annexe 4 - Liste des points de contrôle concernant les algorithmes

1.     Existence d’une note de cadrage. Ce document fondamental a pour but de décrire le futur traitement et tout particulièrement de détailler le ou les algorithmes qu’il va mettre en œuvre. Fait-elle parti d’une étude de faisabilité, d’un cahier des charges, ou tout autre document de spécification ? Qui a participé à son élaboration et sa rédaction ? Est-ce que ce document est clair et compréhensible ? Est-ce que le ou les algorithmes sont convenablement identifiés et décrits ? A-t elle été validée et par qui ?

2.     Le périmètre et le contenu fonctionnel de chaque algorithme doivent être clairement défini. Est-ce que les fonctions à mettre en œuvre sont clairement définies ? Est-ce que ce périmètre est stabilisé et aucune fonction importante n’a été oublié ? Est-ce que ces fonctions sont techniquement réalisables ? Qui a participé à leur définition ? Qui a validé ces spécifications ?

3.     La liste des fonctions mise en œuvre par l’algorithme. Il est nécessaire d’avoir une liste des fonctions à mettre en œuvre car il arrive souvent que certaines fonctions sont oubliées lors des études amonts. L’ajout de ces fonctions en cours de développement ou après la mise en production explique une partie de la dérive des coûts des projets, l’allongement des délais et, finalement, le coût anormalement élevé de la maintenance.

4.     Un schéma explique le fonctionnement de l’algorithme. Souvent un schéma permet de mieux comprendre ce qui est attendu de l’algorithme. Est-ce qu’il existe ? Est-ce que ce schéma est clair ? Est-ce qu’il est commenté ? Est-il accompagné d’exemples permettant de comprendre le fonctionnement de l’algorithme décrivant notamment les résultats attendus ?

5.     Existence d’un recensement des exceptions et des cas particuliers. Il existe presque toujours des situations où l’algorithme ne s’applique pas ou nécessite de mettre en œuvre un traitement différent des cas usuels. Ces développements peuvent majorer de manière significative les coûts de réalisation de l’algorithme. Est-ce que ce recensement a été fait ? Est-ce que des cas particuliers sont apparus en cours de réalisation, voir au-delà ? Est-ce qu’un travail de simplification a été effectué afin de réduire le nombre et l’ampleur des cas particuliers ?

6.     Analyse des spécifications de l’algorithme et de leur exécution effective. L’auditeur doit pouvoir exécuter chaque fonction de l’algorithme et apprécier leur exécution. Si des exemples de traitement sont fournies dans les documents de conception ou la documentation il les utilisera. Est-ce que les fonctions s’exécutent conformément aux spécifications ? Est-ce que toutes les fonctions prévues ont effectivement été mises en place ? Est-ce que le traitement des cas particuliers et des exceptions est conforme ?

7.     Conformité de ou des algorithmes. S’il existe une réglementation (internationale, légale, professionnelle) il est nécessaire de s’assurer que l’algorithme, et plus généralement l’application, est conforme et qu’applique bien les règles ainsi définies. S’il n’existe pas de réglementation est-ce que l’application est conforme aux usages ?

8.     Evolution fonctionnelle de l’application par rapport aux spécifications d’origine. De nombreux algorithmes restent stables dans le temps alors que d’autres évoluent rapidement. Existe-t-il un document retraçant les ajouts fonctionnels ? Est-il à jour ? Est-il exhaustif ? Est-ce que des fonctions indispensables au bon fonctionnement de l’algorithme ont été oubliées dans les spécifications d’origine ? Est-ce que les ajouts ont changé de manière significative la nature de l’algorithme ? Est-ce que l’activité supportée par l’algorithme a évolué ?

9.     Existence d’un jeu d’essais. Il doit exister un jeu d’essais de permettant de tester de manière complète l’algorithme. Est-ce que l’environnement de développement permet d’exécuter automatiquement le jeu d’essais ? Est-ce qu’il peut être exécuté pas à pas ? Permet-il de restaurer les bases de données d’essais dans leur état initial ? Est-ce qu’il est possible de s’assurer que l’algorithme a été complètement testé et notamment que toutes les fonctions ont été testées au moins une fois ? Est-ce que tous les cas particuliers recensés dans le document de spécifications ont été effectivement testés ?

10.  Existence d’un procès-verbal de réception. A la fin de la phase de réalisation une série de tests doivent être organisés afin de détecter d’éventuelles anomalies. A l’issu de ces opérations des tests sont effectués par les utilisateurs. Cette procédure de réception se traduit par une liste des anomalies détectées ou des réserves effectuées est établie. Est-ce que cette liste existe ? Est-ce qu’elle est exhaustive ? Est- que des anomalies graves non-détectées lors des tests de réception sont apparues à la suite de la mise en production de l’algorithme ?

11.  Existence de tests de charge. Ils permettent de mesurer la capacité de traitement de l’algorithme pour un équipement donné. Généralement on la mesure par le nombre de transactions par seconde ou par les temps de réponse. Est-ce que des tests de ce type ont été effectués ? Quel est la capacité maximale de traitement compte tenu des caractéristiques du site de production ? Est-ce que des anomalies apparaissent lorsque le volume d’opérations s’approche de la capacité de traitement maximale de l’équipement ?

12.  Exécution du jeu d’essais. Il est nécessaire d’effectuer fréquemment des tests en cours de réalisation, lors de la réception et lors de la maintenance ultérieure. Existe-t il un outil d’exécution automatique des jeux d’essais ? Si non comment doit-on exécuter les tests ? Est-ce qu’il existe une plateforme de tests dédiée isolée des systèmes de production ? Peut-on remettre automatiquement les bases de données dans l’état initial après que les tests aient été effectués ?

13.  Mode d’exécution des tests. Peut-on exécuter les tests pas à pas ? Peut-on à tout moment consulter les valeurs des différentes variables ? Y-a-t-il un log d’exécution des tests listant les instructions effectuées et permettant de suivre l’état des différentes variables ?

14.  Études des anomalies constatées. Lors de l’exploitation de l’algorithme il peut arriver que des anomalies surviennent. Elles doivent être systématiquement enregistrées et analysées. Leur saisie peut-elle être faite automatiquement ou doit-elle être saisie manuellement par les utilisateurs. Est-ce qu’il existe une statistique permettant de suivre la fréquence et la gravité des anomalies ? Lorsqu’on effectue des modifications de l’algorithme est-ce qu’on constate une augmentation significative du nombre d’anomalies ?

15.  Analyse des informations données aux utilisateurs. Il est nécessaire de mettre à la disposition des utilisateurs des informations suffisantes pour leur facilité la mise en œuvre l’algorithme soit sur un site Web soit sur un document papier ? Est-ce que ces explications sont facilement accessibles, claires et compréhensibles ? Est-ce qu’une action de formation est organisée ? Quel est l’importance des anomalies dues à une formation insuffisante ?

16.  Messages d’erreurs. En cas d’anomalies ou de manœuvres inadaptées l’utilisateur doit recevoir des messages d’erreurs clairs et compréhensibles. Est-ce effectivement le cas ? Est-ce que le nombre d’anomalies constatées diminue dans le temps ou tend t’il à augmenter  ? Y-a-t-il un FAQ ? Est-il pertinent ? En cas de difficulté persistante l’utilisateur peut-il faire appel à une assistance (on-line, téléphonique ou par mail) et obtenir une réponse rapide ?

17.  Opinion des utilisateurs. L’auditeur doit avoir quelques entretiens avec des utilisateurs réguliers et occasionnels pour apprécier globalement leur degré de satisfaction. Il peut aussi intéressant de consulter des utilisateurs occasionnels. Dans les deux cas on va leur demander d’évaluer la qualité de ou des algorithmes mis en œuvre. Quelle est leur appréciation de la simplicité d’utilisation ? Quelle est l’efficacité des algorithmes ? Quelles sont les difficultés rencontrées pour le mettre en œuvre ? …. ([7])

18.  Remontée des utilisateurs. Il doit exister un dispositif régulier permettant aux utilisateurs de donner leur opinion sur le ou les algorithmes. Est-ce que les utilisateurs peuvent donner leur avis en ligne ? Peuvent-ils faire des suggestions d’amélioration ? Est-ce qu’ils signalent des difficultés ou des anomalies ? Quel est le nombre et la qualité de ces remontées ? Est-ce que des suggestions faites par ce canal sont effectivement mises en œuvre ? …

19.  Tableau de bord de l’algorithme. Des statistiques de production doivent être établies tels que :

·       Le volume d’opérations quotidienne,

·       La charge à l’heure de pointe,

·       Le temps de réponse moyen, le temps de réponse à l’heure de pointe, et le temps de réponse maximal observé,

·       Le nombre d’incidents détectés par jour ou par mois,

·       Le temps de disponibilité de l’algorithme ((temps total-temps d’indisponibilité) / temps total),

·       Le nombre de transactions abandonnées sans aller jusqu’à la fin du traitement,

·        …..

Est-ce qu’il existe une évaluation du risque de saturation compte tenu des capacités des équipements en place ? Quel est l’équipement faisant goulet d’étranglement : poste de travail, réseau, serveur, disque ?

20.  Détection de substitution. Il est nécessaire de s’assurer que l’application en production est bien celle qui est audité et qu’il n’y a aucun dispositif « optimisant » les opérations pendant l’audit ([8]). Le plus simple est de contrôler la similitude des écrans et de l’enchainement des opérations entre l’application se trouvant sur la plateforme de tests et celle se trouvant sur les serveurs de production puis, dans un deuxième temps, s’assurer de l’identité entre les programmes se trouvant sur les deux plateformes : numéro de version, taille du code, comparaison du code source et d’exécuter, … . En cas de doute il est nécessaire de plonger dans le détail du code ou dans les modules DDL ([9]).

---

[1] - Contrairement à ce qui est souvent répété APB comme Parcoursup ne font pas appel à l’Intelligence Artificielle. Ces logiciels reposent sur l’algorithme de Gale-Shapley dit des mariages stables. Lloyd Shapley a reçu le prix Nobel d’économie en 2012 pour la découverte de cet algorithme.

[2] - Traduction du document Wikipédia : IEC 61508 : https://en.wikipedia.org/wiki/IEC_61508

[3] - Notons au passage que ces algorithmes ne recourent pas de l’intelligence artificielle mais à l’algorithme de Gale-Shapley dit des mariages stables : https://fr.wikipedia.org/wiki/Probl%C3%A8me_des_mariages_stables

[4] - Ce travail est nécessaire mais il est normalement effectué ultérieurement une fois le périmètre fonctionnel stabilisé.

[5] - Contrairement à une idée souvent répétée le programme source n’est pas une documentation suffisante même s’il comprend des commentaires. Il faut au moins disposer d’une liste des variables utilisées et des routines mises en œuvre.

[6] - Les bases de données rechargeables permettent de les remettre dans leur état initial tel qu’elles étaient avant les tests sans intervention humaines.

[7] - Les utilisateurs consultés doivent être choisis au hasard par l’auditeur et non par la hiérarchie de l’entreprise. Il ne s’agit pas d’effectuer d’un sondage d’opinion mais de mesurer globalement le degré de satisfaction. Dans certains cas on peut aller plus loin et organiser un vrai sondage d’opinion mais cette démarche va plus loin qu’une démarche d’audit.

[8] - Il s’agit de détecter des dispositifs type « dieselgate ».

[9] - On est dans ce cas à la limite de l’audit mais dans le cas de certification cette recherche est nécessaire