Pages

samedi 27 avril 2019

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

lundi 3 décembre 2018

Assistez à la Conférence du 23 Octobre 2018 comme si vous y étiez

Le Club européen pour la Gouvernance des Systèmes d'information a été crée le 23 Octobre 2008. Pour fêter l'anniversaire de ses 10 ans le Club Français avec le sponsoring d'Acadys a organisé le 23 Octobre 2018 une conférence sur l'actualité de la Gouvernance des SI :

2008-2018 Une décennie de bouleversements numérique a rendu la gouvernance des système d'information est indispensable à la création de valeur.

Cette manifestation a été un vrai succès. Plus de 120 DSI, DI, DG, Responsable de la gouvernance, Consultants, ... se pressaient dans une petite salle en sous-sol juste à côté de l'Opéra. Les intervenants sont des experts de haut niveau, à la croisée de la recherche et la pratique. Ils se sont efforcés de décrypter les raisons des difficultés rencontrées par les entreprises et les administration dans leur processus de transformation numérique. Elle est inévitable mais elles est aussi profondément déstabilisante. Pour la maîtriser il est nécessaire de mettre en oeuvre une démarche de gouvernance des systèmes d'information.

Il n'y aura pas de transformation numérique, sans changement de business model, sans élimination des silos au profit des organisations plus plates et plus fluides, sans implication de la direction générale et du  conseil d'administration, sans mettre en avant les choix stratégique et non les gadgets technologique,... Il n'aura pas de transformation numérique sans qu'il y ait une compréhension du nouveau monde économique qui est en train d'émerger, des entreprises plate-formes, des marchés bi-face et évidement des nouvelles méthodes de marketing et d'organisation.

En 5 minutes

Si vous êtes pressés une vidéo de synthèse résume en 5 minutes ce qui a été dit au cours des 3 h 30 d'exposés et vous montrera l'importance de la gouvernance systèmes d'information pour maîtriser le processus complexe de la transformation numérique. 

Pour en savoir plus

Pour approfondir nous vous conseillons de suivre les vidéos des différentes  interventions (sauf une)  en cliquant sur les images du carrousel. 3 heures d'exposés clairs et compréhensibles qui vous permettrons d'apprécier la gouvernance des systèmes d'information. 

Pour accéder aux vidéos cliquez ici. 

https://www.acadys.com/2018/11/21/10-ans-du-cegsi-paris-23-octobre-2018/

mercredi 21 novembre 2018

Les difficultés rencontrées par les entreprises dans la mise en œuvre de la transformation numérique


par Christophe Legrenzi

Les grandes entreprises annoncent des projets ambitieux en ce domaine. Mais en vérité elles ont du mal avec leur transformation numérique. Le nombre des entreprises du CAC40 qui ont réussis à lancer des produits ou des services innovants avec succès est limité. Encore moins d’entreprises ont réussi à mettre en place une nouvelle organisation. Pourquoi et que peut-on faire pour leur permettre de réussir leur transformation numérique ?
  1. Le Paradoxe de Solow : plus que jamais d’actualité - le véritable et principal défi de la transformation numérique des organisations
Rappel et mise en perspective du Paradoxe de Solow
Robert Merton Solow, Prix Nobel d’Economie 1987, publia le 12 juillet dans le New York Times une critique d’un ouvrage intitulé ‘Manufacturing Matters: The Myth of the Post-Industrial Economy’ de Stephen Cohen et John Zysman paru le 3 juin 1987. Nous verrons que trente ans plus tard cette analyse est d’une actualité incroyable.
Solow reproche essentiellement aux deux spécialistes d’économie internationale à Berkeley de ‘se défiler’ lorsqu’ils constatent que l’industrie américaine n’a pas été en mesure de capitaliser sur la révolution technologique, en particulier l’automatisme. D’autant plus qu’ils affirment dans leur livre : ‘Nous n’avons pas à montrer que les nouvelles technologies constituent une rupture avec les modèles passés de la croissance de la productivité’ …/… Celle-ci est due non seulement sur le potentiel que représentent les technologies, mais plutôt sur comment elles sont réellement utilisées’.
Le commentaire de Solow est cinglant : ‘Ils sont comme tout le monde, quelque peu gênés par le fait que ce que l’on pense comme étant une révolution technologique, engendrant un changement drastique de la productivité, a été observé partout, incluant le Japon, soit une baisse de croissance de la productivité, et non une augmentation. Vous pouvez voir l’ère de l’informatique partout, sauf dans les statistiques de la productivité’.
C’est cette dernière phrase, véritable ‘pavé dans la marre’, que reprendront de nombreux analystes et autres commentateurs.

Validité du Paradoxe de Solow

Evidemment, ce qui était vrai il y a 30 ans, ne l’est plus forcément aujourd’hui. De nombreux détracteurs de Solow expliquent que les études macro-économiques ne considèrent pas toujours le délai de latence entre l’investissement et le moment où la valeur se crée réellement. Ceci est un argument pertinent, mais pas le fond du problème.
Plus récemment des économistes brillants et nobélisables comme Robert J. Gordon (‘The Rise and Fall of American Growth, 2016)’ ou encore Larry Summers (‘La stagnation séculaire’, 2016) et Paul Krugman ont démontré sur la base de chiffres très récents que le Paradoxe de Solow était toujours d’actualité.
Même Klaus Schwab, fondateur et patron du World Economic Forum affirme dans son ouvrage de 2017 ‘The Fourth Industrial Revolution’ : « Lors des dernières décennies, la productivité mondiale est restée atone, malgré la croissance exponentielle des progrès technologiques et des investissements dans l’innovation » (‘The Conference Board, Product Brief 2015)  
Klaus Schwab précise : « Cette très récente incarnation du paradoxe de la productivité – la perception de l’échec de l’innovation technologique de créer des niveaux de productivité supérieur est l’une des plus grandes énigmes économique qui précède la grande dépression, et pour laquelle il n’y a pas d’explication satisfaisante »
A l’évidence, et comme nous l’avons souvent écrit : « la technologie seule n’a aucune chance de créer une quelconque valeur ». Il s’agit, ni plus, ni moins, d’un fantasme ou encore d’une utopie technologique issue de la paresse humaine à sur-simplifier des problématiques complexes !

Confirmation récente en France du Paradoxe de Solow


Un rapport très récent, puisqu’il date d’octobre 2018, de la Fabrique de l’Industrie et de France Stratégies (‘L’investissement des entreprises françaises est-il efficace ?’) indique que l’investissement immatériel en France (logiciels, BDD, etc.) est bien plus important que dans les autres pays européens, sachant que depuis dix ans les entreprises françaises ont un niveau d’investissement globalement plus élevé. Depuis 1995, la France investit dans l’immatériel en moyenne 3 fois plus que ses principaux rivaux. Pourtant, elle n’est pas plus productive, ni compétitive que ces collègues, bien au contraire.
En parallèle, comme le mentionne Philippe Rosé dans l’éditorial de son dernier numéro de Best Practices (N°222) : « La huitième édition du Top 250 des éditeurs de logiciels français, réalisée par Syntec numérique et EY, révèle que le secteur se porte très bien. La croissance du chiffre d’affaires a atteint 12 % en 2017. Avec 15 milliards d’euros, c’est un doublement par rapport à 2010…/… ‘Les éditeurs ont su développer des modèles économiques pérennes, qui mènent à la rentabilité, 81 % d’entre eux ont été profitables en 2017’, souligne Jean-Christophe Pernet, associé EY en charge de l’étude. »
D’un côté, l’on constate une décroissance forte de la productivité, de l’autre côté, une croissance forte de l’activité. Il y a forcément une explication voire une corrélation.
Aussi, nous ne pouvons apporter qu’une modeste précision au Paradoxe de Solow : « A l’instar des éditeurs, le ‘Producteur des technologies et services informatiques’, crée de la valeur, alors que le ‘Consommateur’, n’en crée pas, bien au contraire. »
Voilà le principal et véritable défi de la transformation numérique à relever : faire mentir le Paradoxe de Solow !


  1. Le point de vue de McKinsey (cf. papier ‘Why digital strategies fail’ de janvier 2018)
Seulement 8% des entreprises interrogées par McKinsey reconnaissent leur business model économiquement viable si leur industrie continue à se numériser à cette vitesse.
L’article mentionne 5 problématiques qui d’après l’expérience de McKinsey seraient clés :
  1. Définitions floues
Peu de responsables avec lesquels discute McKinsey auraient une idée claire du digital.
Pour McKinsey le digital est la capacité de relier en temps réel, de manière gratuite et sans encombre les personnes, les objets et les produits physiques où qu’ils soient.
Ces équipements auraient déjà créé ces 2 dernières années 90% des données jamais produites. Ces données permettraient d’arriver à des niveaux d’automatisation bien supérieurs, des processus et des décisions, donnant lieu à de tout nouveaux business models.
Manquant clairement de définition du digital les entreprises auraient les plus grandes difficultés à relier la stratégie numérique à leur business.
  1. Incompréhension de l’économie du numérique
    Le digital détruit les rentes établis
    et les dirigeants se doivent d’apprendre rapidement comment se battre, créer de la valeur pour leurs clients, en en gardant pour eux-mêmes dans un monde où les profits se réduisent
    Le digital favorise le syndrome du ‘winner takes it all’ comme l’auraient montré certaines études de McKinsey où il apparait que le premier quart des entreprises d’un secteur progresserait alors que les trois autres quarts verraient leur croissance diminuer.
Le digital favorise les premiers et les suiveurs ultra rapides, la croissance sur 3 ans pour les premiers serait double des entreprises plus conservatrices. Cela serait dû à l’apprentissage et aux méthodes employées de type agile ou prototypage bien plus rapides.
  1. L’oubli de l’eco-système
    Les plateformes rendront les models traditionnels obsolètes. Or, ils ne viennent pas des compétiteurs traditionnels… Il n’y aurait que 3% des acteurs actuels qui adopteraient une stratégie offensive de plateforme.
  1. Sur focalisation sur le suspect habituel
    La plupart des entreprises se focalisent sur la menace des start-ups, alors que la véritable menace émane des grandes entreprises qui ont une part importante du marché, des clients, une marque, etc. et sont bien plus redoutables une fois leur stratégie d’innovation affirmée. Ils impactent alors 20% de la chaîne de valeur alors que les start-ups nouvellement arrivée ne pèseraient que 5%. 
  1. L’oubli de la dualité digitale
    Une fois la menace de la disruption bien réelle, les entreprises ont tendance à devoir créer quelque chose de totalement nouveau… Or d’après McKinsey il s’agit d’évaluer en priorité le rythme et le degré de changement afin de ne pas perdre de vue son marché actuel. En fonction de ces 2 facteurs, il s’agit de suivre une stratégie adaptée :
    1. Initier des mouvements sans risques
    2. Vivre dans les 2 mondes : anciens et modernes à la fois (si degré de chgt fort)
    3. Devenir agile (si rythme rapide)
    4. Prendre des positions audacieuses 
  1. Notre point de vue : constats et recommandations
Dans un article de recherche publié en 2015, édité à l’occasion du numéro 200 de VSE (Revue de l’Association des Docteurs en Economie et en Sciences de Gestion) et intitulé « Informatique, numérique et système d’information : définitions, périmètres, enjeux économiques », qui, étrangement, caracole en tête des articles les plus lus (cf. Cairns), nous avons résumé les 3 causes majeures empêchant aujourd’hui les entreprises de profiter pleinement des opportunités offertes par la ‘fausse’ « Révolution numérique », que nous préférons appeler plus justement : « Révolution informationnelle et des services ».
Ces 3 causes sont :
  1. La méconnaissance des enjeux financiers liés au numérique et aux systèmes d’information (versus informatique) due à l’absence de définition clairement acceptée et aux limites des systèmes de gestion actuels
  2. L’utopie (voire le fantasme) technologique couplée à l’homéostasie organisationnelle souvent véhiculée par l’industrie informatique laissant croire qu’il suffit d’adopter une nouvelle technologie pour en obtenir les bénéfices
  3. Une gouvernance SI déficiente se traduisant par une absence d’implication de la direction générale ou un manque de courage managérial pour initier les changements qui s’imposent pour créer de la valeur.






Pour s’assurer que les facteurs clés de succès soient bel et bien présents nous avons, basé sur de nombreuses recherches, développé un modèle adressant les différentes thématiques à aborder :