Vous avez probablement vu aborder la question de la maîtrise des décisions prises par les algorithmes qui croisent nos vies (Google Car, Admission post-Bac, recommandation Amazon ...), en particulier dans les articles qui titrent sur le BigData et ses risques.
On en vient très vite à préconiser la disponibilité et l'audit du code ... mais de quoi s'agit-il et qu'est-ce qui se cache derrière cette facile injonction ?
Pour pouvoir auditer un code informatique, il faut en disposer, ce qui en général suppose que le logiciel constitué par le code soit publié sous une forme de licence "libre" (Open Source). Dans ce mode de distribution, il n'y a pas de restriction à l'accès au code.
Attention à ne pas confondre un logiciel Open Source avec un logiciel gratuit (dont le code peut être ouvert ou pas).
Une première difficulté apparaît ici : on trouve de nombreux logiciels qui offrent une licence ouverte (gratuité de l'accès au code) mais un mode de production fermé qui suppose des prestations payantes pour installer et paramétrer le logiciel. On parle ici de "faux Open Source", contrairement au "vrai Open Source" qui se caractérise en général par du code documenté, des documentations détaillées (tutoriels d'installation, ...) et une communauté active (forum, wiki, ...) prête à vous assister gratuitement pour la prise en main du logiciel.
Pour mieux cerner l'intérêt de l'audit de code, voici une liste non-exhaustive des situations qui peuvent nécessiter ce type de démarche :
- Evaluer la maintenabilité d'un logiciel pour lequel une entité, qui en est propriétaire, souhaite confier la maintenance (corrections) et l'évolution à une société spécialisée. On appelle ce métier la TMA (Tierce Maintenance Applicative).
- Evaluer le contenu d'un logiciel pour envisager sa reprise et l'adapter à un besoin différent. On parle ici de "fork".
- Dans la continuité de la loi CADA de 1978 sur la communicabilité des documents administratifs, le code source d'un logiciel développé par une autorité administrative est soumis au même régime, dans l'hypothèse d'un audit par un citoyen qui le souhaiterait (ex: le logiciel de calcul de l’impôt sur le revenu).
- Enfin, le cas de figure évoqué en début d'article, à savoir le contrôle public sur les algorithmes utilisés pour des décisions en rapport avec une mission de service public (transport, santé, éducation, emploi ...). Ce domaine n'est pas complètement couvert par la loi, mais de plus en plus d'experts le demandent.
Donc, si je suis dans un de ces cas de figure et que je dispose du code source, alors "en avant pour l'audit" !
Et là, on a vite fait de se rendre compte que la tâche va être probablement compliquée ...
En effet, quiconque a essayé de se plonger dans le code source d'une application a sans douté été confronté à la difficulté de comprendre le sens d'une fonction, d'interpréter le rôle d'une variable dont le nom n'est pas signifiant ou tout simplement à l'égarement dans les méandres des nombreux fichiers composants l'application.
A moins d'y consacrer un temps considérable, un audit de code ne peut se faire dans un délai raisonnable qu'aux conditions suivantes :
- Disposer d'un code lisible
- Décomposition en unités de taille raisonnable (quelques centaines de lignes maxi)
- Indentation et nommage pertinent des variables et fonctions pour faciliter la lecture
- Disposer d'un code documenté
- Commentaires dans le source pour décrire tout ce qui n'est pas explicite
- Documentations disponibles, en particulier le MCD (Modèle Conceptuel de Données) indispensable pour comprendre la structuration de la base de données, le DAT (Dossier d'Architecture Technique) ...
- Disposer d'un environnement technique conforme
- Ce point est souvent oublié, mais si on n'a pas les plateformes et licences pour pouvoir exécuter le code, il est probable qu'une partie de l'audit restera inachevée
- Bénéficier de la connaissance humaine des concepteurs/développeurs
- Ce point n'est pas toujours possible, mais un transfert de compétences, de la part des équipes qui ont conçu le produit, fera gagner un temps considérable car ce sera l'occasion de capter des éléments non-dits souvent précieux
A partir de là, que peut-on faire pour qu'un hypothétique futur audit de code soit facilité, quand on est dans une autorité administrative qui passe commande d'un logiciel ?
- Promouvoir l'utilisation des logiciels libres
- L'audit bien évidemment facilité par rapport à une solution propriétaire. Il faut donc pousser à ce que les administrations donnent une priorité aux solutions libres, alors que certains signes de l'Etat ne semblent pas aller dans ce sens (dernière version du RGI, accords avec des éditeurs privés, ...).
- Exiger, dans les clauses contractuelles sur la réversibilité, la fourniture, dès la recette :
- du code source
- du MCD, DAT ...
- d'un transfert de compétences sur l'architecture du logiciel
- Prévoir un mini-audit sur la qualité du code livré
Aucun commentaire:
Enregistrer un commentaire