Avant d’installer un outil d’IA, nous lisons son code : open source ne veut pas dire sans risque

Le point de départ : un lien, rarement plus

La plupart des entrées de notre veille commencent de la même façon : un lien envoyé seul, souvent tiré d’un réseau social. Une vidéo de trente secondes qui promet un gain de temps, un billet qui recommande « quatre projets faciles », une publication qui propose le lien du dépôt à qui commentera un mot-clé. Le contenu est le déclencheur, jamais la preuve.

Premier geste, donc : retrouver la source. Le nom du dépôt est presque toujours visible à l’écran, et le retrouver sans jouer le jeu du commentaire suffit déjà à comprendre le mécanisme de diffusion. Il arrive que la vidéo et sa propre capture d’écran se contredisent sur le nombre d’étoiles, du simple au double. Ce n’est pas grave en soi. C’est un rappel : ce que l’on nous dit d’un outil n’est pas l’outil.

La méthode : cinq questions posées au code

Nous clonons le dépôt sur une machine de travail, nous le lisons, et, par défaut, nous n’installons rien. Cinq questions reviennent à chaque fois. Quelle licence, et couvre-t-elle vraiment tout ce qui est livré (le code, les poids d’un modèle, les données) ? Qu’est-ce qui s’exécute sans qu’on le demande : au démarrage, à la mise à jour, en tâche de fond ? Qu’est-ce qui sort de la machine : télémétrie, appels réseau, dépendance à un service distant ? Où sont rangés les secrets, et risquent-ils de finir dans un endroit versionné ? Enfin, qui maintient, et depuis quand personne n’a rien poussé ?

Chaque réponse est datée et sourcée : la ligne de code, le fichier, la date de la vérification. Quand une réponse nous manque, nous l’écrivons comme un trou, pas comme une supposition. Et quand l’outil est prometteur, nous l’essayons sur nos propres fichiers avant de le recommander à qui que ce soit.

Quatre couleurs, et le rouge est le plus fréquent

Chaque dépôt reçoit un ou plusieurs verdicts. Vert : réutilisable tel quel, ou presque. Jaune : une idée ou une structure à reprendre, mais à réécrire chez nous. Rouge : à ne pas garder, parce qu’il pose un problème de sécurité, de licence ou de données, ou parce qu’il est simplement faux. Blanc : à connaître, sans usage immédiat. Un même dépôt peut porter plusieurs couleurs : rouge à l’installation, et pourtant porteur d’une idée qu’on reprend.

Sur tous les verdicts posés depuis juin, le rouge arrive en tête, devant le jaune, puis le vert. Et une poignée d’outils seulement sont installés et en service dans notre atelier. Ce rapport n’est pas du pessimisme. Il dit que la popularité d’un dépôt mesure son audience, pas sa conduite. Et qu’un « non » motivé, écrit une fois, épargne ensuite des heures de doute à chaque fois que le même outil revient dans une conversation.

Ce que la lecture attrape, et que la page d’accueil ne dit pas

Un environnement de travail très suivi, au-delà de cent mille étoiles, installe un script qui, à chaque ouverture de session, récupère la dernière version du dépôt puis l’exécute, en silence. Le README le présente comme un confort : plus jamais de version en retard. Lu au code, c’est du code tiers, non relu, qui s’exécute sur votre poste chaque matin. C’est précisément le type de porte que nous faisons fermer chez nos clients.

Un petit module de synchronisation entre deux outils de prise de notes enregistre la clé d’accès de l’utilisateur en clair, dans un dossier de configuration que beaucoup versionnent avec leurs notes. La clé part alors dans l’historique, et un secret entré dans un historique ne s’en retire pas en supprimant le fichier. Le même module propose un bouton « tout télécharger » qui écrase les notes locales. Aucun de ces deux défauts n’est visible sans ouvrir le code.

Plus loin, une liste « awesome » de plus de deux mille liens dont presque chacun porte un identifiant d’affiliation, et dont le robot de mise à jour échoue chaque jour depuis sa création. Un générateur d’applications « pour les PME » dont la politique dit en toutes lettres que vos contenus servent à entraîner ses modèles. Rien d’illégal dans la plupart de ces cas. Mais ce ne sont pas des outils que l’on pose sous des données clients.

Et ce qu’elle révèle de bon

La veille ne sert pas qu’à dire non. Certains dépôts sont exemplaires, et nous le disons aussi. Le moteur de base de données FoundationDB, publié par Apple sous licence Apache 2.0, n’embarque ni télémétrie ni mise à jour automatique : un bulletin vierge sur les points qui nous importent. Le serveur MCP de data.gouv.fr, publié par un opérateur public sous licence MIT et hébergé en France, s’interroge en lecture seule, et c’est ce qu’il promet.

Notre préféré de la rentrée est un petit module de mise en forme des réponses pour les lecteurs TDAH, sous licence MIT. Son mécanisme de démarrage ne fait rien tant que l’utilisateur ne l’a pas activé lui-même, et n’appelle aucun réseau. Surtout, son auteur publie son propre banc d’évaluation, y compris le verdict d’échec qu’il s’applique à lui-même alors que ses scores progressent. Un dépôt qui documente ses ratés inspire plus confiance qu’un dépôt qui n’en montre aucun. Nous y avons relevé trois idées pour nos propres outils d’accessibilité.

Enfin, le jaune est souvent le verdict le plus fécond. Un outil qu’on n’installera jamais peut contenir un bon motif : une façon de découper le travail d’un agent, de rendre une décision traçable, de mesurer ce qu’une consigne change vraiment. Nous le notons, puis nous le réécrivons chez nous, à notre échelle, sur nos machines.

Une veille qui vit dans nos murs

Cette veille n’est pas un tableur partagé chez un tiers. C’est une note de notre base de connaissances, qui alimente l’onglet Veille de notre portail interne, servi par une machine installée au cabinet. Quand un dépôt est retenu, il devient une piste de travail ; quand il est écarté, la raison reste écrite, avec sa date. Le jour où quelqu’un nous montre de nouveau le même outil, la réponse existe déjà, et elle se relit en deux minutes.

Ce que nous gardons et que nous écrivons nous-mêmes, nous le publions en retour, sous licence ouverte, et nous posons à notre propre code les cinq mêmes questions. C’est la moindre des choses quand on lit celui des autres.

Ce que cela change pour vous

Une équipe qui adopte un outil d’IA n’adopte pas qu’une interface. Elle adopte ce qui s’exécute au démarrage, ce qui part sur le réseau et ce que l’éditeur fera demain de ce qu’il reçoit. Ces réponses sont presque toujours écrites quelque part, dans le code ou dans une politique d’utilisation. Il suffit d’aller les lire avant d’installer, et de garder une trace de ce qu’on a lu.

C’est ce que nous faisons pour nous, et c’est ce que nous faisons pour nos clients : l’outil que votre équipe veut adopter, nous le lisons avant qu’il touche vos données, et nous vous rendons un verdict daté, en langage clair, avec ce qu’il faut régler pour le garder. Parfois le verdict est vert. Souvent, il faut juste fermer une porte avant d’entrer.