Dans le cadre des 20 ans de Fedora-fr et du Projet Fedora en lui-même, Nicolas Berrehouc alias Nicosss et moi-même (Charles-Antoine Couret alias Renault) avons souhaité poser des questions à des contributeurs francophones du Projet Fedora et de Fedora-fr.

La diversité des profils permet de voir le fonctionnement du projet Fedora sous différents angles, au-delà de la distribution, mais aussi comment il est organisé et conçu. Certains points s’appliquent d’ailleurs à d’autres distributions.

N’oublions pas que le Projet Fedora reste un projet mondial et un travail d’équipe, ce que ces entretiens ne permettent pas forcément de refléter. Mais la communauté francophone a la chance d’avoir suffisamment de contributeurs et de contributrices de qualité pour permettre de donner un aperçu de beaucoup de sous-projets de la distribution.

Chaque semaine un nouvel entretien sera publié sur le forum Fedora-fr.org, LinuxFr.org et le blog de Renault.

L’entretien du jour concerne Timothée Ravier, contributeur au Projet Fedora en particulier aux systèmes dits immuables et à l’environnement KDE Plasma.

Sommaire

• Conclusion

Bonjour Timothée, peux-tu présenter brièvement ton parcours ?

J’ai commencé à m’intéresser aux logiciels open source autour de 2004 lorsque j’ai découvert Firefox (version 1.0 à l’époque) par l’intermédiaire d’un ami qui l’a téléchargé pour moi sur un CD ré-inscriptible, car je n’avais pas encore l’ADSL à l’époque. J’ai ensuite découvert Linux avec Ubuntu 6.06. Après mes études d’ingénieur en sécurité informatique, j’ai travaillé à l’ANSSI pendant cinq ans sur le projet CLIP OS et je travaille désormais pour Red Hat où je co-dirige l’équipe CoreOS, qui est responsable de la maintenance de Fedora CoreOS et de Red Hat Enterprise Linux CoreOS pour OpenShift.

Peux-tu présenter brièvement tes contributions au Projet Fedora ?

Mes contributions à Fedora sont liées à mon intérêt pour les systèmes orientés conteneurs, parfois dénommés immuables (immutable). Je fais ainsi partie de l’équipe qui maintient Fedora CoreOS, je suis un mainteneur des Fedora Atomic Desktops (principalement Silverblue et Kinoite) et je suis membre du KDE Special Interest Group (SIG).

Qu’est-ce qui fait que tu es venu sur Fedora et que tu y es resté ?

Je suis passé par plusieurs distributions Linux (Ubuntu, Gentoo, Arch Linux) mais je suis désormais sur Fedora.

Je pense que les « Four Foundations » de Fedora représentent bien mon parcours :

• Freedom : Je suis là parce que je suis intéressé par les logiciels libres, car ils permettent un partage, une mise en commun au bénéfice de tous.
• Features, First : C’est la force de la communauté Fedora d’un point de vue technologique. Je développe ce point dans les questions suivantes.
• Friends : Je me suis fait des amis dans la communauté Fedora et cela contribue à la bonne ambiance et la motivation pour continuer à contribuer.

Pourquoi contribuer à Fedora en particulier ?

Je préfère être proche des projets upstream et des dernières évolutions. C’est pour cela que j’étais pendant un long moment sous Arch Linux.

Mais le processus pour pousser des changements dans Arch Linux était plutôt flou. Il est important de noter que cela a peut-être changé désormais. Mon expérience date de plus de 6 ans et je crois qu’ils ont un processus de RFC maintenant. Le fonctionnement d’Arch Linux impose aussi des mises à jour régulières et une certaine discipline lors des mises à jour liée au modèle de développement sans version fixe.

Je commençais alors à m’intéresser de plus en plus aux systèmes à base d’images (CoreOS Container Linux et Fedora Atomic Host à l’époque) et je suis donc allé voir Fedora Atomic Workstation (ancien nom de Silverblue) pour créer une version à base de l’environnement KDE Plasma, qui est devenue Fedora Kinoite.

Le processus pour pousser des changements dans Fedora est ce qui fait la force de la distribution. Il permet d’obtenir des discussions et des décisions sur les évolutions à apporter à la distribution pour la prochaine version.

Contribues-tu à d’autres Logiciels Libres ? Si oui, lesquels et comment ?

En dehors de Fedora, je contribue principalement au développement des projets KDE. Je fais partie de l’équipe qui maintient les applications KDE empaquetées avec Flatpak et publiées sur Flathub.

Je contribue aussi occasionnellement à différents projets open source en fonction des besoins.

Utilises-tu Fedora dans un contexte professionnel ? Et pourquoi ?

Oui, mes ordinateurs professionnels et personnels tournent sous Fedora Kinoite et mes serveurs personnels utilisent Fedora CoreOS. Une partie des serveurs que nous utilisons pour développer et produire les versions de Fedora CoreOS sont aussi sous Fedora CoreOS. D’autres sont sous Red Hat Enterprise Linux CoreOS, car ils font partie d’un cluster OpenShift.

En gros, nous sommes aussi des utilisateurs directs des logiciels que nous développons.

Est-ce que tes contributions dans Fedora se font entièrement dans le cadre de ton travail ? Si non, pourquoi ?

Une grosse partie de mes contributions se font dans le cadre de mon travail, mais toute la partie liée à KDE et aux Fedora Atomic Desktops est faite sur mon temps personnel.

Est-ce que être employé Red Hat te donne d’autres droits ou opportunités au sein du Projet Fedora ?

Je n’ai pas plus de droits dans Fedora parce que je travaille pour Red Hat. Je dois suivre tous les processus de Fedora comme n’importe quel contributeur. J’ai d’ailleurs commencé à contribuer à Fedora avant d’avoir été employé par Red Hat.

En revanche, il est indéniable que cela m’aide pour contribuer, car j’ai régulièrement l’occasion de discuter avec d’autres contributeurs Fedora dans le cadre de mon travail.

Tu as débuté une carrière dans la sécurité pour finalement travailler pour Red Hat en tant que mainteneur de CoreOS, Silverblue, Kinoite et contributeur à KDE, pourquoi ne pas avoir continué dans la sécurité pour cet écosystème ?

Quelque part je continue à faire de la sécurité mais sous un autre angle. La sécurité que je faisais avant ne bénéficiait qu’à un petit nombre de personnes qui avait accès aux systèmes que l’on développait. La nouvelle version open source de CLIP OS devait rendre le système plus accessible mais le projet était complexe et je crois qu’il est désormais archivé.

Je travaille désormais à améliorer la sécurité de Fedora CoreOS et des Fedora Atomic Desktops sans compromettre leur utilisabilité. L’objectif est de fournir une distribution Linux avec des mises à jour robustes qui soit utilisable par des non développeurs.

Tu participes à CoreOS pour RHEL, CentOS Stream et Fedora. Peux-tu expliquer le but de CoreOS et ses principales caractéristiques ? Quelles sont les différences entre RHEL, CentOS Stream et Fedora à ce sujet ?

L’objectif pour les systèmes CoreOS est de faire tourner au mieux des applications dans des conteneurs. Pour Fedora CoreOS, c’est un système minimal, avec des mises à jour automatiques, proposant à la fois podman et moby-engine (Docker) installés par défaut, prêt à faire tourner des conteneurs sur un seul nœud ou dans le cadre d’un cluster Kubernetes.

Pour Red Hat Enterprise Linux CoreOS (et CentOS Stream CoreOS), ce sont des systèmes qui forment le socle d’OpenShift (et d’OKD), une plateforme qui intègre plein de projets open source dont Kubernetes.

Bien qu’il n’y ait pas une correspondance exacte un pour un dans la liste des logiciels inclus, Fedora CoreOS est l’upstream de CentOS Stream CoreOS et Red Hat Enterprise Linux CoreOS, de la même façon que Fedora est l’upstream de CentOS Stream, qui l’est de Red Hat Enterprise Linux.

L’architecture atomic a gagné du terrain sur les systèmes pour le bureau avec Silverblue et Kinoite et devient relativement populaire, peux-tu expliquer quel en est l’intérêt d’une telle conception pour ce genre de systèmes ?

Le principal intérêt pour un utilisateur est la robustesse et rapidité des mises à jour. Celles-ci sont préparées en arrière plan alors que le système fonctionne normalement. Il suffit alors de redémarrer pour mettre à jour son système. Il n’y a pas d’attente supplémentaire ni à l’extinction ni au démarrage.

Si une mise à jour échoue, le système reste dans l’état actuel, et il est possible de réessayer plus tard.
Si une mise à jour introduit un problème important empêchant le démarrage du système par exemple, il est possible de redémarrer et de choisir la version précédente dans le menu de démarrage de GRUB.

Les utilisateurs sont aussi poussés à utiliser Flatpak pour installer leurs applications graphiques et toolbox (ou distrobox) pour utiliser les applications en ligne de commandes dans des conteneurs.

Quels sont les défis techniques de proposer cette conception dans ces systèmes par rapport à CoreOS par exemple ?

La principale différence est la présence d’une interface graphique. Les applications graphiques doivent être parfois adaptées pour fonctionner avec Flatpak. C’est désormais le cas de la plupart d’entre elles.

Tu y contribues en tant que membre de Fedora Atomic Desktops SIG, peux-tu expliquer son rôle dans Fedora et ton activité dedans ?

Le rôle du Fedora Atomic Desktops SIG est de regrouper l’ensemble des contributeurs Fedora des différentes variantes Atomic : Silverblue, Kinoite, Sway Atomic et Budgie Atomic. Bien que chacun de ces systèmes propose un environnement de bureau distinct, ils partagent énormément d’éléments, tant au niveau des composants de base du système que de l’infrastructure Fedora. Le SIG permet donc de regrouper les contributeurs pour pouvoir les inclure dans les prises de décisions qui impactent ces systèmes.

Je participe à la maintenance des Fedora Atomic Desktops et plus principalement de Silverblue et Kinoite. Cela peut impliquer des mises à jour de paquets, des corrections de bugs dans des projets upstream ou des rajouts de fonctionnalités pour améliorer l’expérience sur ces systèmes. Je surveille aussi que tous les Atomic Desktops continuent de recevoir des mises à jour régulièrement.

Penses-tu qu’un jour ces systèmes atomic deviendront la référence par défaut ? Si oui à quelle échéance ? Quelles sont les difficultés actuelles à résoudre ?

Je l’espère ! Il est impossible de donner une échéance et cela ne dépend pas vraiment de moi. La difficulté la plus importante est la prise en charge du matériel et les pilotes qui ne sont pas intégrés dans Fedora. C’est un problème que l’on ne peut pas résoudre dans Fedora à cause des contraintes légales et qui sont traitées par le projet Universal Blue, dont la variante Bazzite (https://bazzite.gg/), est très populaire.

Pour la problématique des pilotes, est-ce que l’initiative du noyau unifié (d’avoir une image universelle et signée comprenant le noyau, initrd, la ligne de commande) te semble être une solution à cette problématique ?

Ces deux sujets ne sont pas liés.

Le problème des pilotes externes au noyau Linux upstream est divisé en deux cas principaux :

• Les pilotes propriétaires : Ils ne seront jamais ajoutés directement à Fedora pour des raisons légales et de licence.
• Les pilotes open source mais non inclus dans le noyau Linux upstream : Fedora met à jour le noyau Linux très régulièrement et suit les nouvelles versions stables peu de temps après leur sortie officielle. Il faut donc que ces pilotes soient mis à jour pour suivre les nouvelles versions du noyau et cela demande toujours du temps lorsque ceux-ci ne font pas partie du noyau upstream.

Les images noyau unifiées (Unified Kernel Images ou UKI) incluent le noyau, l’initrd et la ligne de commande du noyau dans un seul fichier. Cela présente des avantages pour mettre en place une chaîne de boot mesurée, notamment à l’aide du TPM, et donc pour offrir de meilleures garanties de sécurité. Leur intégration est encore en cours dans les variantes CoreOS et Atomic Desktops.

Les développeurs et administrateurs systèmes ont souvent besoin d’outils qui à ce jour nécessitent souvent de recourir à rpm-ostree plutôt que Flatpak ou Fedora toolbox dans le cadre d’un système immuable. Penses-tu que ces verrous sont un réel problème et qu’ils seront éventuellement résolus dans le temps ?

L’un des objectifs de la nouvelle initiative conteneurs bootables (« Bootable Containers ») est justement de rendre plus ergonomique la modification du système de base. Le système est distribué sous forme d’une image de conteneur standard (image OCI) et il est possible de la modifier à l’aide d’un Containerfile / Dockerfile et d’outils natifs aux conteneurs. Cela permet aux utilisateurs de ré-utiliser leurs habitudes et outils pour modifier aussi leur système de façon sûre et de partager le résultat à l’aide d’un registre d’image de conteneurs.

Nous allons aussi ajouter à nouveau dnf (version 5) dans ces images de conteneurs pour mettre à disposition des utilisateurs une interface familière et toutes les options de dnf lors de la construction de ces images.

Une autre piste est d’utiliser le concept des extensions systèmes de systemd (systemd system extensions ou sysexts), qui permettent d’ajouter du contenu dynamiquement à un système sans perdre les avantages de la gestion à base d’images. Les sysexts utilisent la même technologie que pour les conteneurs (overlayfs) pour ajouter des éléments (merge) au contenu des dossiers /usr et /opt de l’image de base. Je suis en train d’investiguer cette option pour rendre son usage ergonomique pour ces systèmes : https://github.com/travier/fedora-sysexts.

Il est aussi possible de modifier temporairement le système en utilisant un système de fichier temporaire monté au-dessus des emplacements en lecture seule (overlayfs). Les fichiers de /usr peuvent alors être modifiés et de nouveaux paquets RPM installés à la demande. Les modifications disparaîtront au redémarrage.

Tu participes aussi à l’équipe de KDE SIG, peux-tu expliquer son rôle dans Fedora et ton activité dedans ?

L’objectif du KDE SIG est de proposer la meilleure expérience possible de KDE sur Fedora. Nous suivons et contribuons aussi au développement de KDE upstream.

Je participe au KDE SIG en tant que mainteneur de Kinoite et développeur KDE.

GNOME reste le bureau principal de Fedora à ce jour, cependant la qualité de l’intégration de KDE progresse depuis de nombreuses années maintenant, penses-tu que la qualité entre les deux est aujourd’hui équivalente ? Est-ce que les contributions pour KDE sont freinées de par le statut de GNOME au sein du projet ?

C’est une question très difficile, car elle est très subjective. J’utilise principalement KDE sur mes systèmes, mais j’apprécie énormément le travail de design fait sur GNOME. Pour moi c’est un choix personnel.

D’un point de vue technologique, il est possible de trouver des éléments “meilleurs” dans GNOME que dans KDE et l’inverse.

Il n’y a pas de bénéfice à opposer ces deux projets. C’est au contraire la collaboration qui améliore l’expérience utilisateur.

Je ne pense pas que les contributions à KDE soient freinées par le status de GNOME dans Fedora.

L’équipe KDE SIG a récemment proposé d’améliorer le statut de KDE au sein du projet, quitte à même remplacer GNOME pour Fedora Workstation, peux-tu expliquer cette demande ? Penses-tu qu’un jour KDE remplacera GNOME au sein de Fedora ou de RHEL par exemple ?

L’idée des membres soutenant cette proposition (qui ne vient pas uniquement de personnes faisant partie du KDE SIG) est de remettre en question la place de GNOME « par défaut » dans le projet Fedora (notamment Fedora Workstation). Poser cette question force le projet à clarifier les critères qui font qu’un environnement de bureau est considéré comme majeur et donc autorisé à être représenté par une “édition” comme Fedora Workstation. Tous les environnements de bureau non-GNOME ne sont actuellement pas bien présentés sur le site de Fedora notamment.

Il est important pour un projet communautaire de pouvoir justifier ses choix, que l’on soit d’accord ou non avec les arguments présentés. Si ces choix sont perçus comme arbitraires (« c’est comme ça que cela a toujours été », « c’est un employé de Red Hat qui l’a décidé »), alors le projet Fedora perd en crédibilité. Il faut, par exemple, pouvoir justifier que GNOME est un bon choix à présenter aux utilisateurs découvrant Fedora.

Je ne pense pas que KDE va “remplacer” GNOME dans Fedora et ce n’est pas vraiment l’idée derrière cette proposition qui a été formulée explicitement de la sorte pour forcer la discussion. L’objectif est de rendre KDE plus visible dans Fedora.

Pour ce qui est de remplacer GNOME dans RHEL, c’est peu probable et cela serait une décision de Red Hat.

Penses-tu que Fedora est une distribution de référence pour utiliser KDE aujourd’hui ? Par le passé OpenSUSE, Kubuntu ou Mageia étaient souvent recommandées pour utiliser cet environnement.

Oui ! :) Fedora propose depuis plusieurs années les dernières versions de KDE à des fréquences très proches des sorties upstream. Nous sommes actuellement l’une des premières distributions à proposer le bureau KDE Plasma dans sa version 6. Le KDE SIG suit et participe activement au développement de KDE upstream et certains développeurs KDE recommandent désormais Fedora.

Je travaille avec Fedora Kinoite à rendre le développement de KDE plus abordable, notamment pour le test des versions en cours de développement.

Si tu avais la possibilité de changer quelque chose dans la distribution Fedora ou dans sa manière de fonctionner, qu’est-ce que ce serait ?

Je regrouperai l’intégralité des dépôts Git, codes sources, projets, suivi des bugs, etc. sur une (ou plusieurs) instance GitLab hébergée par le projet Fedora. C’est un projet qui est désormais en cours pour migrer vers Forgejo. Finies les instances Pagure (forge de développement Git), plus de Bugzilla (suivi des bugs). Il faudrait aussi abandonner les listes de diffusion pour utiliser Discourse à la place (transition aussi en cours).

D’un point de vue personnel, la migration du projet KDE vers GitLab fut un facteur déterminant dans ma capacité à contribuer au projet KDE. Le mode de contributions à l’aide de Pull Requests / Merge Requests à travers une interface web est devenu un standard qui réduit significativement la difficulté pour un premier contributeur à participer à un projet.

Je pense que c’est la prochaine étape importante pour rendre le développement de Fedora plus accessible et donc pour attirer plus de contributeurs.

À l’inverse, est-ce qu’il y a quelque chose que tu souhaiterais conserver à tout prix dans la distribution ou le projet en lui-même ?

Le processus pour proposer un changement (Change Process). C’est la clé de ce qui fait de Fedora une distribution à la pointe, qui évolue à chaque nouvelle version et qui pousse l’écosystème en avant.

Que penses-tu de la communauté Fedora-fr que ce soit son évolution et sa situation actuelle ? Qu’est-ce que tu améliorerais si tu en avais la possibilité ?

Malheureusement, je n’ai pas eu beaucoup d’interactions avec la communauté Fedora-fr, donc je n’ai pas grand-chose à dire.

Quelque chose à ajouter ?

Merci pour l’entretien !

Si vous souhaitez en apprendre plus sur ces systèmes, je vous recommande les documentations officielles des projets ou les présentations que j’ai réalisées (une ou deux en français).

Merci Timothée pour ta contribution !

Conclusion

Nous espérons que cet entretien vous a permis d’en découvrir un peu plus sur les systèmes immuables de Fedora et l’environnement KDE Plasma.

Si vous avez des questions ou que vous souhaitez participer au Projet Fedora ou Fedora-fr, ou simplement l’utiliser et l’installer sur votre machine, n’hésitez pas à en discuter avec nous en commentaire ou sur le forum Fedora-fr.

À dans 10 jours pour un entretien avec Thomas Canniot, ancien traducteur de Fedora en français et fondateur de l’association Fedora-fr.

Ces derniers temps, on a beaucoup parlé d’intelligence artificielle sur LinuxFr.org. D’IA propriétaires, et d’IA libres. Mais peut-on vraiment faire une IA libre ? La notion n’est pas sans poser quelques difficultés. Une (pas si) courte discussion du problème.

Sommaire

• On appellera IA un réseau de neurones artificiels
• Pour comprendre le réseau de neurones, il est nécessaire de disposer de bases statistiques
  • Les statistiques reposent sur la modélisation
    • Un exemple : la régression linéaire
• Le réseau de neurones
  • Le neurone naturel
  • Le neurone formel
  • La mise en réseau
  • Le réseau de neurones est Turing-complet
  • Le réseau de neurones présente un effet boîte noire important
  • Le réseau de neurones est un modèle statistique
    • Tous les modèles sont faux, certains sont utiles, et c’est vrai aussi pour le réseau de neurones
• Le but du logiciel libre est de rendre le pouvoir à l’utilisateur
  • La première des libertés est celle de savoir ce que je fais
  • Si je sais ce que je fais, je dois pouvoir modifier ce que je fais
• Le réseau de neurones est difficilement compatible avec le libre
  • Personne ne sait vraiment ce que fait un réseau de neurones
  • Disposer de la description complète d’un réseau de neurones ne permet pas de l’améliorer
  • La définition du code source d’un réseau de neurones est ambiguë
  • Cette ambiguïté fait courir un risque juridique sous certaines licences libres
    • Comment les boîtes qui font de l’IA non libre résolvent-elles ce dilemme ? Elles ne le résolvent pas
  • La définition d’une IA open source ressemble furieusement à un constat d’échec
• Conclusion : qu’attendre d’une IA libre ?

On appellera IA un réseau de neurones artificiels

Commençons par définir notre objet d’étude : qu’est-ce qu’une IA ? Par « intelligence artificielle », on pourrait entendre tout dispositif capable de faire réaliser par un ordinateur une opération réputée requérir une tâche cognitive. Dans cette acception, un système expert qui prend des décisions médicales en implémentant les recommandations d’une société savante est une IA. Le pilote automatique d’un avion de ligne est une IA.

Cependant, ce n’est pas la définition la plus couramment employée ces derniers temps. Une IA a battu Lee Sedol au go, mais ça fait des années que des ordinateurs battent les humains aux échecs et personne ne prétend que c’est une IA. Des IA sont employées pour reconnaître des images alors que reconnaître un chien nous semble absolument élémentaire, mais l’algorithme de Youtube qui te suggère des vidéos pouvant te plaire parmi les milliards hébergées fait preuve d’une certaine intelligence et personne ne l’appelle IA. Il semble donc que le terme « IA » s’applique donc à une technique pour effectuer une tâche plus qu’à la tâche en elle-même, ou plutôt à un ensemble de techniques partageant un point commun : le réseau de neurones artificiels.

Dans la suite de cette dépêche, j’utiliserai donc indifféremment les termes d’IA et de réseau de neurones¹.

Pour comprendre le réseau de neurones, il est nécessaire de disposer de bases statistiques

Les statistiques (ou la statistique, on peut dire les deux, comme en Alexandrie), c’est la branche des mathématiques qui s’intéresse aux moyens, à partir de données observées et fondamentalement probabilistes, d’en tirer des conclusions généralisables (et idéalement, de prédire l’avenir à partir du passé).

La data science, c’est la branche de l’informatique qui s’intéresse aux moyens, à partir de données emmagasinées sur lesquelles on ne fait pas d’hypothèse de mode de génération, d’en tirer des conclusions généralisables (et idéalement, de prédire les données futures).

Ça vous semble similaire ? Ça l’est. Les deux champs vont avoir des divergences de vocabulaire, de langages (les stateux préfèreront R, les data scientists Python), de formation (les stateux sont plutôt des universitaires, les data scientists plutôt des informaticiens au niveau licence, mais ils ont les mêmes masters et doctorats), mais fondamentalement, et surtout mathématiquement, c’est la même chose. Les connaissances en inférence statistique (notamment bayésienne, pour ceux à qui ça parle) se généralisent très bien à la data science.

Pour faire court, un statisticien est un data scientist qui se la pète, alors qu’un data scientist est un informaticien qui, n’étant pas assez bon pour survivre à la rude concurrence universitaire, a multiplié son salaire par 10 ou 20 en allant vendre ses compétences statistiques à Facebook.

Les statistiques reposent sur la modélisation

En statistique, la manière la plus courante de répondre à une question est de construire un modèle. Prenons une question simple : je dispose d’un jeu de données où j’ai enregistré, pour 1000 personnes, leur IMC et leur taux de cholestérol. Je souhaite savoir s’il y a un lien entre les deux. On souhaiterait, dans ce cas simple, rechercher une relation monotone, sans faire d’hypothèse sur le type de relation.

Un exemple : la régression linéaire

Une manière de répondre à ma question est d’écrire et de trouver les meilleurs A et B pour que la droite « colle » le mieux possible au nuage de points. On démontre que la meilleure droite est celle qui minimise un certain critère, la somme des carrés des erreurs. Une fois qu’on a la meilleure droite possible, on peut faire plein de choses avec :

• On peut rétro-prédire le taux de cholestérol des personnes déjà observées et voir de combien la prédiction s’écarte du réel, ce qui fournit une erreur moyenne de prédiction ;
• On peut faire de même en prédisant juste le taux de cholestérol moyen pour tous les individus et comparer les erreurs moyennes de prédiction, ce qui permet de voir de combien le modèle améliore la prédiction (et donc de quantifier la quantité d’info apportée par la donnée IMC sur la variable cholestérol) ;
• On peut étudier le signe de A : si A est négatif, prendre du poids fait baisser le cholestérol : si A est positif, prendre du poids augmente le cholestérol : si A est nul, le poids n’apporte pas d’info sur le cholestérol.
• Par contre, on ne peut rien dire de la causalité. Tout ce qu’on a observé, ce sont des personnes qui, au même moment, avaient un IMC et un taux de cholestérol donnés. Impossible de dire s’ils ont ce cholestérol parce qu’ils ont cet IMC, s’ils ont cet IMC parce qu’ils ont ce cholestérol, ou s’ils ont ce cholestérol et cet IMC parce qu’ils ont une troisième exposition.
• On peut enfin faire effectuer de la prédiction à notre modèle : en lui passant une personne dont on ne connaît que l’IMC, on peut estimer son taux de cholestérol et assortir cette prédiction d’un niveau de certitude (ça demande un peu plus de maths, mais c’est l’idée).

On peut vouloir ajouter une troisième variable, mettons le tabagisme. On écrira alors :

Avec la variable tabac codée à 0 (non fumeur) ou 1 (fumeur). Noter que notre modèle est alors passé en dimension 3 : on ne cherche plus à faire passer la meilleure droite par rapport au nuage de points en 2D, mais à faire passer le meilleur plan par rapport au nuage de points en 3D. Noter aussi qu’on peut facilement inclure des variables qualitatives : il suffit de les coder 0 ou 1. On peut d’ailleurs inclure des variables à n modalités : il suffit de les recoder en n-1 sous-variables en 0-1 (la modalité de référence étant celle pour laquelle toutes les sous-variables sont à 0).

Les sont appelés des paramètres : c’est en les faisant varier qu’on ajuste le modèle aux données.

On peut ainsi ajouter un nombre quelconque de variables… Ou peut-être pas. En effet, on va finir par atteindre un seuil où le meilleur hyperplan est tout simplement celui qui passe par tous les points ! Si j’ai 50 individus et 50 paramètres, il est facile de choisir un plan qui passe par tous les individus. C’est ce qu’on appelle le surapprentissage : le modèle a tout simplement appris le jeu de données par cœur ! Le surapprentissage est un écueil des modèles trop complexes et un réseau de neurones est tout à fait capable de surapprendre.

Le réseau de neurones

Le neurone naturel

Les neurones sont les cellules du système nerveux. Elles sont spécialisées dans la transmission d’information.

Comme tu peux le voir sur cette image issue de Wikimedia (source), un neurone comprend un nombre quelconque de dendrites, un corps cellulaire, et un axone. Point crucial : l’axone est unique. Il peut lui-même transmettre de l’information à différents neurones en aval, mais il transmet la même information. Or l’information, dans un neurone, peut entrer par les dendrites et par le corps cellulaire, mais elle ne peut ressortir que par l’axone (on peut faire abstraction de la gaine de myéline et des nœuds de Ranvier, qui ont un rôle central dans la vitesse de conduction de l’information mais qui ne changent rien aux calculs effectués). Autrement dit, un neurone transmet la même information à tous les neurones d’aval, et si ceux-ci en font un usage différent, c’est uniquement lié à leurs propres calculs en interne.

Le neurone formel

On peut modéliser un neurone, par analogie avec le neurone naturel. Notre neurone formel pourra donc prendre un nombre quelconque d’entrées, mais comme un neurone naturel, il ne produira qu’une seule sortie. Notre neurone est donc une fonction de ses entrées :

En pratique (mais ça n’a rien d’obligatoire), on prend souvent une fonction d’une combinaison linéaire des entrées :

Avec une contrainte : la fonction (qu’on appelle fonction d’activation) doit être monotone (idéalement strictement monotone), dérivable presque partout (c’est nécessaire à l’optimisation du réseau, qu’on verra plus tard), définie sur un intervalle suffisamment large pour qu’on soit toujours dedans, et non linéaire (sinon mettre les neurones en réseau n’a aucun intérêt, autant faire directement une unique régression linéaire).

En pratique, on prend donc quelques fonctions classiques :

• La fonction binaire : si , sinon
• La fonction logistique, une amélioration de la fonction binaire : . Avantage : elle est strictement monotone, dérivable partout, et elle prend quand même ses valeurs entre 0 et 1.
• La fonction Rectified Linear Unit (ReLU, qu’on peut prononcer « relou ») : si , sinon. Avantage : elle est très facile (donc rapide) à calculer et à dériver. On peut la rendre strictement monotone en la modifiant à la marge : si , sinon, avec .

La mise en réseau

Tout l’intérêt du neurone formel réside dans sa mise en réseau. Un unique neurone ne fait pas mieux qu’une régression linéaire. On construit donc un réseau de neurones. Pour ce faire, on va donc générer plusieurs neurones, chacun prenant en entrée la sortie de plusieurs neurones et produisant une sortie unique, qui sera à son tour utilisée en entrée par d’autres neurones. On ajoute un ensemble de neurones qu’on pourrait qualifier de « sensitifs », au sens où ils prennent en entrée non pas la sortie d’un neurone antérieur, mais directement l’input de l’utilisateur, ou plutôt une partie de l’input : un pixel, un mot… Enfin, une sortie est ajoutée : elle produit le résultat final.

Étant donné que les neurones sont virtuels et n’ont pas d’emplacement géographique, il est assez logique de les représenter en couches : la couche 0 est constituée des neurones sensitifs, la couche 1 prend en entrée les résultats de la couche 0, et ainsi de suite. Classiquement, tous les neurones de la couche n+1 prennent en entrée les sorties de tous les neurones de la couche n.

Se pose alors la question : combien de neurones par couche, et combien de couches au total ?
On peut considérer deux types de topologies : soit il y a plus de neurones par couche que de couches : le réseau est plus large que long, on parlera de réseau large. Soit il y a plus de couches que de neurones par couche, auquel cas le réseau est plus long que large, mais on ne va pas parler de réseau long parce que ça pourrait se comprendre « réseau lent ». On parlera de réseau profond. C’est de là que viennent les Deep et les Large qu’on voit un peu partout dans le marketing des IA. Un Large Language Model, c’est un modèle, au sens statistique, de langage large, autrement dit un réseau de neurones avec plus de neurones par couche que de couches, entraîné à traiter du langage naturel. On constate empiriquement que certaines topologies de réseau sont plus efficaces pour certaines tâches. Par exemple, à nombre de neurones constant, un modèle large fera mieux pour du langage. À l’inverse, un modèle profond fera mieux pour de la reconnaissance d’images.

Le réseau de neurones est Turing-complet

Un résultat théorique important est que les réseaux de neurones sont Turing-complets. C’est-à-dire que, pour tout programme que l’on peut coder et qui sorte une réponse algorithmique, il existe un réseau de neurones qui donne le même résultat. La réciproque est vraie aussi : ce qui est faisable avec un réseau de neurones est faisable en C ou dans un autre langage, au pire en recodant le réseau dans ce langage.

Le réseau de neurones présente un effet boîte noire important

Prenons maintenant un élément d’information et essayons de suivre son trajet dans le modèle jusqu’à la sortie. Dans une régression linéaire, c’est assez facile : le poids de l’IMC va peser pour dans le résultat final. Dans une forêt aléatoire, on peut toujours isoler les arbres où apparaît une donnée et essayer de regarder combien elle pèse. C’est fastidieux mais ça reste faisable. Dans un réseau de neurones, c’est impossible. Chaque neurone de la couche 1 va passer un résultat agrégé à la couche 2, où chaque donnée de la couche 0 ne compte plus que comme partie d’un tout. De même, chaque neurone de la couche 2 va agréger tous les résultats de la couche 1. Il devient impossible d’individualiser l’effet d’une donnée ou même celui d’un neurone.

Ainsi, même si je connais l’intégralité du contenu du modèle, il m’est impossible de donner du sens à une partie du modèle, prise isolément. Le modèle se comporte comme un bloc monolithique, et la seule manière d’étudier un nouvel exemple est de lui appliquer tout le modèle et de voir ce qui sort. C’est ce qu’on nomme l’effet boîte noire.

Attention : l’effet boîte noire n’est pas lié au nombre de paramètres du modèle. Si je fais de la génétique, et que j’étudie 2000 mutations génétiques individuelles (des SNP, pour single nucleotide polymorphism), je peux assez facilement ajuster un modèle de régression logistique (qui est une variante de la régression linéaire où on fait prédire non pas une variable quantitative, mais une probabilité) à 2000 paramètres (un pour chaque SNP). Chaque paramètre sera parfaitement compréhensible et il n’y aura pas d’effet boîte noire.

Il n’est pas non plus lié à ta méconnaissance des mathématiques, cher lectorat. Des statisticiens chevronnés se cassent les dents sur l’effet boîte noire. Il est intégralement lié à la structure du modèle. Certains types de modèles en ont, d’autres n’en ont pas. Les réseaux de neurones en ont.

Cet effet a une conséquence perturbante : même si on sait ce que fait un réseau de neurones, il est impossible de savoir comment il le fait ! On pourrait argumenter que ce n’est pas forcément différent de ce que nous faisons : si on montre à un enfant de 3 ans une photo de chien, il saura dire que c’est un chien, mais il ne saura pas dire pourquoi c’est un chien. Cependant, on demande rarement à un programme d’être réflexif, mais on demande toujours à son auteur de savoir comment il tourne. C’est un peu la base de la programmation.

Le réseau de neurones est un modèle statistique

Reprenons : on a un paradigme (le réseau de neurones) capable d’effectuer n’importe quelle tâche pour laquelle il existe une solution algorithmique, à condition de le programmer correctement… Mais on ne sait pas le programmer ! Heureusement, il existe un contournement : on ne va pas le programmer, on va l’ajuster, comme un modèle statistique. Ou l’entraîner, si on préfère le terme de « machine learning ».

Tu t’en souviens, cher lecteur, un réseau de neurones est un ensemble de fonctions dont chacune prend en entrée différentes données avec des coefficients (les fameux ). On va commencer par initialiser l’apprentissage en donnant des valeurs aléatoires à ces coefficients. Ensuite, on va soumettre à notre réseau de neurones des tas et des tas de données correctes, et qu’on va comparer ce qu’il prédit à ce qu’on attend. La différence s’appelle l’erreur. Et à chaque itération, on va identifier les neurones les plus générateurs d’erreur et les pénaliser (réduire leur poids, ou plutôt réduire leur poids dans les neurones où c’est nécessaire), tout en favorisant les meilleurs neurones. Les détails de la technique (qui s’appelle la rétropropagation de l’erreur) dépassent largement le cadre de cette courte introduction, mais l’essentiel est qu’à la fin, on obtient un réseau capable de donner des réponses proches de ce qui existait dans l’ensemble des données correctes qu’on lui a passé et de généraliser quand la demande est différente d’une donnée de l’ensemble d’apprentissage. Avantage : en pratique, un réseau de neurones est capable de prendre en entrée n’importe quel type de structure de données : image, texte, son… Tant que les neurones d’entrée sont adaptés et qu’il existe un ensemble d’apprentissage suffisamment grand, c’est bon.

Tous les modèles sont faux, certains sont utiles, et c’est vrai aussi pour le réseau de neurones

Bien sûr, il y a des limites. La première est la complexité algorithmique. Un réseau de neurones nécessite de réaliser un nombre astronomique d’opérations simples : pour chaque couche, il faut, pour chaque neurone, calculer la somme des produits des coefficients avec toutes les sorties de la couche antérieure, soit multiplications, où n est le nombre de neurones par couche et c le nombre de couches. Par exemple, pour un petit réseau de 10 couches de 20 neurones, plus une couche d’entrée, on réaliserait à chaque itération multiplications en virgule flottante, et encore, c’est ici un tout petit réseau : un réseau comme ChatGPT a des neurones qui se comptent par millions, voire dizaines de millions !

Une autre limite est la précision des réponses. Le réseau de neurones étant un modèle statistique, il n’est capable que d’interpoler, c’est-à-dire trouver une réponse à partir de cas similaires. Cette interpolation est rarement aussi précise que celle que donnerait une réponse formelle si elle existait : si Newton avait eu accès à des réseaux de neurones, nous aurions une prédiction du mouvement des planètes qui ne baserait sur aucune théorie, qui serait à peu près exacte mais insuffisamment précise pour envoyer des sondes sur Mars. Quant à s’interroger sur la précession du périhélie de Mercure, on oublie.

De manière générale, on peut s’interroger sur ce qui amène un réseau de neurones à se planter. On peut diviser les erreurs en plusieurs catégories :

• La question posée n’a aucun rapport avec les données passées en entrée. Par exemple : « Sachant que la dernière personne que j’ai croisée dans la rue avait 42 ans, indique-moi son genre ». Le modèle n’a pas assez d’information pour répondre.
• La question posée n’a aucun rapport avec l’ensemble d’apprentissage. Par exemple, demander à un modèle entraîné à reconnaître des photos de chien de reconnaître une voiture. En général, ce problème est résolu en contraignant le format des questions ; dans cet exemple, il suffirait de ne pas permettre à l’utilisateur de poser une question, juste de poster une photo et de recevoir une réponse. D’ailleurs, on ne voit pas très bien pourquoi entraîner un tel modèle à traiter du langage.
• L’ensemble d’apprentissage est trop restreint/biaisé. L’exemple typique est le modèle qui prétendait reconnaître les délinquants à une simple photo et identifiait en fait tous les noirs : ben oui, ils étaient majoritaires dans les délinquants de l’ensemble d’apprentissage. Noter qu’il existe des problèmes où l’ensemble d’apprentissage sera toujours trop restreint pour un certain niveau de précision exigé. Si on demande à un réseau de dire si un point donné est à l’intérieur ou à l’extérieur d’un flocon de Koch, il va falloir lui passer une infinité de données d’apprentissage pour qu’il apprenne les cas limites juste par interpolation (alors qu’avec un modèle formel, ça serait assez facile).
• Le modèle est parasité par une donnée annexe : c’est une problématique assez spécifique du réseau de neurones. L’exemple le plus classique est celui des images de mains : après tout, le voisin le plus probable d’un doigt, c’est un autre doigt. L’amusant, c’est que ce problème serait résolu assez facilement en demandant au modèle de compter 4 doigts et un pouce. Mais comme on ne peut pas programmer directement un réseau de neurones…
• Enfin, si les motifs précédents ont été écartés, je dois me demander si mon modèle n’est pas inadapté : soit qu’il n’a pas assez de neurones, soit que la topologie n’est pas bonne. Plus de neurones permettent de traiter des données plus complexes et leur disposition permet d’augmenter leur efficacité.

En définitive, on peut voir le réseau de neurones comme un outil qui résout approximativement un problème mal posé. S’il existe une solution formelle, et qu’on sait la coder en un temps acceptable, il faut le faire. Sinon, le réseau de neurones fera un taf acceptable.

Le but du logiciel libre est de rendre le pouvoir à l’utilisateur

On a beaucoup glosé, et on continuera de le faire longtemps, sur la philosophie du Libre. Free Software Foundation d’un côté, Open Source Initiative de l’autre, les sujets de discorde ne manquent pas. Mais il faut au moins créditer l’OSI sur un point : avoir clarifié le fait que le Libre est avant tout un mouvement politique, au sens noble du terme : il vise à peser sur la vie de la cité, alors que l’Open Source vise avant tout à disposer de logiciels de qualité.

La première des libertés est celle de savoir ce que je fais

Ça paraît évident dans la vie de tous les jours : je sais ce que je fais. Si je décide de prendre une pelle et de planter un arbre dans mon jardin, je sais que je suis en train de prendre une pelle et de planter un arbre dans mon jardin. Si je décide de prendre un couteau et de le planter dans le thorax de mon voisin, je sais ce que je fais. C’est une liberté fondamentale, au sens où elle fonde toutes les autres. Si je ne sais pas ce que je fais, je ne peux signer un contrat, par exemple (c’est d’ailleurs le principe qui sous-tend le régime de la tutelle en droit). D’ailleurs, comme toute liberté, elle fonde une responsabilité. Si je ne savais pas ce que je faisais (et que je peux le prouver), je peux plaider l’abolition du discernement et échapper à ma responsabilité pénale, quelle que soit l’infraction commise, même les plus graves²

Dans la vie de tous les jours, donc, il est évident que je sais ce que je fais. Mais avec un ordinateur, c’est beaucoup moins évident. Quand j’exécute Windows, je ne sais pas ce que je fais. Pas seulement parce que je ne connais pas la séquence de boot, mais de façon beaucoup plus fondamentale : parce que n’ayant pas accès au code source, je ne sais pas ce que fait le programme que j’exécute. Ce qui pose un problème majeur de confiance dans le logiciel exécuté :

• Confiance dans le fait que le programme fait bien ce que son programmeur a voulu qu’il fasse (absence de bugs)
• Confiance dans le fait que le programmeur avait bien mon intérêt en tête et pas seulement le sien (sincérité du programmeur, fréquemment prise en défaut dans le logiciel non libre)

Dans le système des 4 libertés du logiciel libre, cette liberté est la liberté 1. Elle passe après la liberté 0 (liberté d’exécuter le programme) et avant la liberté 2 (liberté de redistribuer le programme). On pourrait légitimement discuter de sa priorité par rapport à la liberté 0 (est-il raisonnable d’exécuter un programme dont on ne sait pas ce qu’il fait ?) mais ça dépasserait l’objet de cette dépêche.

Si je sais ce que je fais, je dois pouvoir modifier ce que je fais

Conséquence logique de la liberté précédente : si je n’aime pas ce que fait un programme, je dois pouvoir l’améliorer. Si je ne sais pas le faire moi-même, je dois pouvoir payer quelqu’un pour l’améliorer. Là encore, ça suppose l’accès au code source, ne serait-ce que pour savoir ce que fait le programme. Il s’agit de la liberté 3 du logiciel libre.

Le réseau de neurones est difficilement compatible avec le libre

Personne ne sait vraiment ce que fait un réseau de neurones

On l’a vu, les réseaux de neurones présentent un effet boîte noire important. Déjà, la plupart des IA commerciales ne sont accessibles qu’au travers d’une interface ou une API. Elles n’exposent que rarement les neurones. Mais même pour une personne disposant de tous les neurones, autrement dit de la description complète du réseau, l’effet boîte noire est tel que le fonctionnement du réseau de neurones est inintelligible. D’ailleurs, s’il était intelligible, il serait très vite simplifié !

En effet, on peut recoder tout réseau de neurones dans un langage plus rapide, dès lors qu’on comprend ce qu’il fait (puisqu’il est Turing-complet). Vu la consommation astronomique d’énergie des réseaux de neurones, s’il existait un moyen de comprendre ce que fait un réseau de neurones et de le traduire dans un autre langage, on le ferait très vite. Ce qui fournirait d’ailleurs des réponses à des questions théoriques ouvertes comme : qu’est-ce que comprendre une phrase ? Comment reconnaît-on un chien, un visage, un avion ?

Disposer de la description complète d’un réseau de neurones ne permet pas de l’améliorer

On l’a vu : si je dispose de la totalité des neurones, je dispose de la totalité de la description du réseau de neurones. Mais comme je suis incapable de savoir ce qu’il fait, je ne suis pas plus avancé pour l’améliorer, qu’il s’agisse de retirer un défaut ou d’ajouter une fonctionnalité. Noter d’ailleurs que ceci n’est pas forcément impactant de la même manière pour tous les aspects du réseau de neurones : si je n’ai aucun moyen d’être sûr de l’absence de bugs (c’est même le contraire ! Il y a forcément des bugs, c’est juste que je ne les ai pas trouvés ou qu’ils ne sont pas corrigeables), j’ai en revanche peu d’inquiétude à avoir concernant la sincérité du programmeur : comme lui non plus ne maîtrise pas sa bestiole, pas de risque qu’il soit insincère³.

La définition du code source d’un réseau de neurones est ambiguë

Posons-nous un instant la question : qu’est-ce que le code source d’un réseau de neurones ? Est-ce la liste des neurones ? Comme on l’a vu, ils ne permettent ni de comprendre ce que fait le réseau, ni de le modifier. Ce sont donc de mauvais candidats. La GPL fournit une définition : le code source est la forme de l’œuvre privilégiée pour effectuer des modifications. Dans cette acception, le code source d’un réseau de neurones serait l’algorithme d’entraînement, le réseau de neurones de départ et le corpus sur lequel le réseau a été entraîné.

Cette ambiguïté fait courir un risque juridique sous certaines licences libres

Tu devines alors, cher lecteur, là où je veux en venir… Si le corpus comprend des œuvres non libres, tu n’as tout simplement pas le droit de le diffuser sous une licence libre ! Et si tu t’es limité à des œuvres libres pour entraîner ton modèle, tu risques fort d’avoir un ensemble d’apprentissage trop restreint, donc un réseau de neurones sans intérêt.

Alors il y a quatre moyens de tricher.
Le premier, c’est de t’asseoir sur la GPL et de considérer qu’en distribuant les neurones, tu as fait le taf. La ficelle est grossière. Je viens de passer une dépêche à te démontrer que c’est faux, tu pourrais au moins me montrer un peu plus de respect.

Le deuxième, c’est de distribuer sous une licence non copyleft, genre BSD ou WTFPL. Une licence qui ne nécessite pas de distribuer le code source. Certes, mais en fait tu ne fais pas du Libre.

Le troisième, c’est de considérer le réseau de neurones comme une donnée, pas un exécutable. Donc pas de code source. La partie sous GPL serait alors l’interface graphique, et le réseau, une donnée. C’est assez limite. Une donnée exécutable, ça s’approche dangereusement d’un blob binaire.

Le quatrième, c’est de repenser complètement le paradigme du logiciel libre et de considérer qu’il vise avant tout à rééquilibrer les rapports de pouvoir entre programmeur et utilisateur, et qu’en redistribuant les neurones, tu as fait le job. Sur les rapports de pouvoir, tu n’as pas tort ! Mais d’une part, ça ne tiendra pas la route devant un tribunal. D’autre part, il persiste une asymétrie de pouvoir : tu as accès au corpus, pas l’utilisateur.

Quand bien même on admettrait que le code source est l’ensemble corpus + algorithme d’optimisation + réseau de neurones de départ, l’optimisation d’un réseau de neurones consomme autrement plus de ressources que la compilation d’un programme plus classique, des ressources qui sont loin d’être à la portée du quidam classique. À quoi servirait un code source impossible à compiler ?

Enfin, même cette définition du code source pose problème : elle n’est en fait pas beaucoup plus lisible que le réseau lui-même. Ce n’est pas parce que j’ai accès aux centaines (de milliers) de textes sur lesquels un réseau a été entraîné que je peux prédire comment il va se comporter face à une nouvelle question.

Comment les boîtes qui font de l’IA non libre résolvent-elles ce dilemme ? Elles ne le résolvent pas

C’est presque enfoncer une porte ouverte que dire que l’IA pose de nombreuses questions de droit d’auteur, y compris dans le petit microcosme du non-libre. Cependant, les IA non-libres ont un avantage sur ce point : si le réseau de neurones ne permet pas de remonter au corpus initial (donc en l’absence de surapprentissage), alors elles peuvent tranquillement nier avoir plagié une œuvre donnée. Tu ne me verras pas défendre les pauvres auteurs spoliés, car j’ai toujours considéré que la nature même de l’information est de circuler sans barrières (Information wants to be free, tout ça) et que le droit d’auteur en est une, et particulièrement perverse.

La définition d’une IA open source ressemble furieusement à un constat d’échec

L’OSI a publié une définition d’IA open source. Cette définition mérite qu’on s’y attarde.

Premier point intéressant : après des années à tenter de se démarquer du Libre, notamment via la définition de l’Open Source qui tente de reformuler les 4 libertés sans recopier les 4 libertérs, l’OSI baisse les bras : est open source une IA qui respecte les 4 libertés.

Deuxième point intéressant : est open source une IA qui publie la liste des neurones, le corpus d’entraînement et la méthode d’entraînement. En fait, ça revient à ne pas choisir entre les neurones et leur méthode d’entraînement. Soit, mais ça ne résout pas le problème de l’effet boîte noire. Au mieux, ça revient à admettre qu’il est le même pour le programmeur et l’utilisateur.

Conclusion : qu’attendre d’une IA libre ?

Il ne fait aucun doute que développer des IA libres exigera de nouvelles licences. La GPL, on l’a vu, expose à un risque juridique du fait de l’ambiguïté de la définition du code source.

Il est à noter, d’ailleurs, qu’une IA repose rarement exclusivement sur son réseau de neurones : il y a systématiquement au moins un logiciel classique pour recueillir les inputs de l’utilisateur et les passer au réseau de neurones, et un second en sortie pour présenter les outputs. Ces briques logicielles, elles, peuvent tout à fait suivre le paradigme classique du logiciel libre.

En définitive, cher lecteur qui ne développes pas d’IA, je t’invite surtout à te demander : qu’attends-tu d’une IA ? Qu’entends-tu quand on te parle d’IA libre ? Plus fondamentalement, l’IA serait-elle un des rares domaines où il existe une distinction pratique entre libre et Open Source ?

Il n’y a pas de façon simple de faire une IA libre, il n’y a peut-être pas de façon du tout. Mais le principe du libre, c’est que c’est à l’utilisateur in fine de prendre ses décisions, et les responsabilités qui vont avec. Je n’espère pas t’avoir fait changer d’avis : j’espère modestement t’avoir fourni quelques clés pour enrichir ta réflexion sur le sens à donner au vocable IA open source qu’on voit fleurir ici et là.