Intervention de Simon Chignard

De mémoire, ce nombre est de l'ordre de 3 000 à 6 000 personnes, sur 850 000 candidats.

Le code source d'APB pallie en outre l'absence de réglementation, et le manque d'évolution de la loi. C'est aussi un enjeu pour le futur, que de mieux faire converger la loi et les traitements informatiques.

Cet aspect me permet de souligner qu'il existe une différence fondamentale entre le fait d'écrire une loi et celui de créer un logiciel. Le législateur, le juriste, et l'administration, adorent et appellent l'interprétation. On apprécie que le texte ne soit pas très précis, puisque cela permet ainsi de traiter une multitude de cas concrets. Prenons un exemple simple dans APB, en l'occurrence la question du « domicile du candidat ». Comment interpréter cette expression ? Cela renvoie-t-il à son académie, à sa commune de résidence, à son département, à sa région, au nombre de kilomètres qui le séparent de l'université la plus proche, voire pourquoi pas au temps de transport, en mode individuel ou collectif ? Vous constatez, à partir de cet exemple a priori simple, le nombre de questions que cela soulevées.

À la différence du législateur ou du juriste, le codeur informatique n'apprécie pas l'interprétation. La machine n'aime pas le flou. Tout ceci est évidemment à relativiser dans le cadre de dispositifs apprenants, et d'intelligence artificielle, qui constituent un tout autre sujet.

Très clairement, ceci pose une difficulté fondamentale : on n'écrit pas un code source comme on écrit le code dans la loi. Si le code fait loi – je fais ici allusion à la déclaration, voici dix-sept ans, de Lawrence Lessig, professeur de droit à Harvard : « code is law » –, alors il faut qu'il soit rendu public. Ceci semble évident. Personne n'imagine, dans un pays jouissant d'une tradition démocratique comme la France, que l'on puisse vous arrêter dans la rue en vous accusant d'avoir enfreint la loi, sans vous indiquer à quelle loi il est fait référence. De la même manière, on ne peut concevoir qu'un système algorithmique prenne une décision sans qu'il soit possible d'en connaître les modalités d'élaboration.

Il n'existe pas de bonne solution dans ce domaine. En revanche, il y aura un équilibre à trouver et un choix à faire entre, d'une part, disposer d'un système efficace et explicable, et, d'autre part, le degré de convergence souhaité entre droit écrit, droit public, et code informatique. Je laisserai la direction générale des finances publiques nous parler d'un autre retour d'expérience, dans un contexte très différent, qui montre qu'il est tout à fait possible de faire converger droit et informatique, notamment via l'usage de la doctrine. Mais il s'agit d'un autre sujet.

La mission Etalab a travaillé pour essayer de comprendre de quelle façon l'ouverture permettait d'améliorer le système. Je pense ainsi que le fait d'ouvrir le code est non seulement prévu dans la loi pour une République numérique, promulguée en octobre 2016, mais constitue aussi un facteur nécessaire d'amélioration du fonctionnement de la plateforme.

J'en viens, en quelques mots, à la généralisation de cette réflexion. En 2015, le sociologue Dominique Cardon a publié un ouvrage intitulé À quoi rêvent les algorithmes ? Il s'agit d'une bonne question, qui n'est toutefois pas celle que nous avons entrepris de traiter au sein d'Etalab. À défaut de savoir à quoi ils rêvent, nous nous sommes focalisés sur l'utilité des algorithmes.

On voit très clairement aujourd'hui que les algorithmes sont utilisés dans de très nombreux domaines de l'action publique, dans lesquels ils aident à prendre des décisions. Celles-ci concernent, par exemple, les individus : calcul des impôts, des aides personnalisées au logement (APL), éligibilité à certaines aides, etc. D'autres sont plus subtiles. Ainsi, certaines collectivités recourent à des algorithmes pour prioriser les dossiers de demande de logement social. L'administration utilise également beaucoup d'algorithmes pour gérer ses ressources humaines : la gestion de l'avancement, de la mobilité ou des traitements et salaires fait ainsi massivement appel à des algorithmes. Ces derniers servent aussi à prendre des décisions concernant des personnes morales, par exemple dans le domaine de la lutte contre la fraude sociale et fiscale. L'administration emploie aussi des algorithmes pour prendre des décisions vis-à-vis d'autres administrations, comme le calcul par l'État de la dotation globale de fonctionnement des collectivités, qui s'apparente à un algorithme. En l'occurrence, la procédure n'est ni transparente, ni explicite, ni toujours compréhensible pour les personnes concernés.

Par conséquent, il nous semble que les algorithmes sont des outils puissants et précieux, permettant parfois de factualiser la décision, ce qui constitue un élément important. Ils apportent aussi un gain de temps, comme l'exemple de la refonte d'APB le montrera. Ils sont également gage de performance et de finesse dans la décision. Il faut sortir de l'idée que l'humain est la garantie absolue contre de nombreux biais que l'on n'aurait pu évaluer. L'algorithme, s'il est clair, transparent, explicite et redevable, peut en effet constituer un appui sérieux. L'humain aussi possède des biais, peut commettre des erreurs de jugement, et n'est pas toujours en mesure d'expliciter les raisons de ses décisions.

Notre approche, au sein de la mission Etalab et de la DINSIC, consiste à proposer une démarche de poids et contrepoids, de checks and balances, pour reprendre une notion anglo-saxonne propre au domaine des institutions : celle-ci consiste à considérer que l'usage des algorithmes est très clairement une opportunité pour l'action publique, sous réserve que des principes de responsabilité soient appliqués. Nous avons ainsi dégagé trois principes susceptibles de rendre les algorithmes responsables. Ces principes ne sont pas exclusifs l'un de l'autre et devraient être appliqués dès la conception et tout au long de la vie du système.

Le premier est le principe de transparence : un système responsable doit viser la transparence dans toutes ses dimensions. Ceci concerne notamment l'ouverture des codes sources, des données et la publication des objectifs. M. Bernard Koehret a mentionné précédemment le fait que le hackaton, prévu à l'origine pour septembre 2017, n'avait pas eu lieu. Ceci résulte effectivement d'une décision du ministère de ne pas ouvrir, à ce stade, le code source.

Le second critère, moins souvent explicité, mais tout aussi essentiel, renvoie au fait qu'un système responsable doit être explicable, a fortiori lorsqu'il intervient dans la sphère publique. Il faut pouvoir expliquer aux individus concernés, et plus globalement à la société, de manière complète, fidèle et compréhensible, ce que fait vraiment le système. Ceci a constitué un vrai sujet dans APB. Les fantasmes induits ont été à la hauteur de l'opacité du dispositif, qui générait une grande incompréhension sur le fonctionnement du logiciel. Par exemple, il est arrivé que certains lycéens se plaignent en ligne qu'APB leur ait refusé l'entrée dans telle ou telle classe préparatoire. Or, la décision ne relève pas d'APB, mais d'un humain, par exemple un responsable de filière, qui a décidé de choisir plutôt d'autres candidats.

La Déclaration des droits de l'homme et du citoyen comporte enfin un principe, consistant à rendre des comptes. Tout agent de l'administration doit rendre compte de son action aux citoyens. Un système équivalent pourrait être développé pour les algorithmes de la puissance publique, consistant à dire qu'un système responsable doit pouvoir rendre des comptes, c'est-à-dire non seulement être transparent et explicable, mais aussi permettre l'établissement d'un dialogue avec les concepteurs et exploitants des algorithmes. Tout citoyen devrait avoir la possibilité d'exercer un droit de recours, et de faire évaluer les impacts de l'utilisation des algorithmes de manière régulière, pas uniquement au moment où une nouvelle solution est lancée.

J'espère être parvenu, en ouverture de cette seconde table ronde, à établir le lien entre APB et d'autres problématiques d'algorithmes publics.