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 |
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.
[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
