L'IA qui nous intéresse ne répond pas aux e-mails : ce que nous avons fait avant de demander une seule réponse à l'intelligence artificielle

Ces dernières années, j’ai vu TikTok être inondé de créateurs de contenu expliquant comment mieux utiliser l’intelligence artificielle, en explorant astuces et conseils. Dans le même temps, des entreprises comme Anthropic, OpenAI et diverses sociétés chinoises — entrées dans cette course depuis un bon moment déjà — se sont mises à lancer des outils de plus en plus tournés vers la productivité.

Pendant ce temps, un vif débat sur la régulation et l’éthique de l’IA, discuté depuis des années, se poursuivait. Depuis le début de l’année, je me creuse la tête pour savoir comment utiliser tout cela de façon plus concrète dans notre quotidien. Beaucoup d’organisations ont lancé des défis pour que l’intelligence artificielle produise de l’impact social — mais une bonne partie d’entre eux paraît encore éloignée de notre réalité. Éloignée parce que, bien souvent, l’ambition de résoudre de grands problèmes avec l’IA nous semble encore un peu irréaliste.

Même si je crois que tout cela est possible, la différence tient peut-être à la vision du monde : nous sommes davantage préoccupés de comprendre comment l’intelligence artificielle peut nous aider aujourd’hui — dans la périphérie, dans la favela, dans la réalité de nos programmes d’éducation et d’innovation sociale, ici à la Casa Hacker. Comment peut-elle être plus réactive ? Comment peut-elle nous aider à décider au quotidien ?

L’évidence ne suffit pas

Dans un premier temps, les organisations et les entreprises technologiques pensent souvent que l’évidence suffit : acheter des licences ChatGPT, Claude et d’autres outils, et les distribuer aux salariés sans discernement. Mais où passe le soin apporté à la protection des données, aux informations stratégiques ? Dans quelle mesure les gens se préparent-ils vraiment à rendre leurs données accessibles à l’intelligence artificielle ?

Ici, à la Casa Hacker, nous manipulons des centaines de PDF chaque jour — finances, pédagogie, éducation, innovation sociale — auxquels s’ajoutent des tableurs, des documents texte et des fichiers produits par les systèmes de nos partenaires et par l’analyse de données. Garantir que tout cela soit lu et traité en sécurité par l’IA est un défi énorme. En pratique, ce défi devient même plus grand et plus urgent que l’adoption de l’intelligence artificielle elle-même dans notre quotidien.

C’est dans cet esprit que, il y a quelques mois, nous nous sommes lancé un défi à la Casa Hacker : réunir notre base de données et la préparer pour l’intelligence artificielle.

C’est la partie de l’histoire que j’ai déjà racontée dans un autre texte. Voici maintenant la suite — ce que nous avons réellement fait, ce qui a raté, et ce que nous avons appris et qui peut servir à toute organisation se trouvant au même point.

Partie 1 — Où nous en étions

Une précision d’abord : quand je parle de notre système, je parle du Cockpit. C’est la plateforme de gestion que nous avons construite pour la Casa Hacker elle-même — ce n’est pas un produit que nous vendons. C’est là que vivent les projets, les contrats, les finances, le budget, les achats, les factures, le juridique, les stages, l’inventaire du matériel et le suivi pédagogique. Il est né pour remplacer une poignée de plateformes propriétaires, chacune avec sa licence, sa base fermée et son export en tableur.

En août 2026, le Cockpit conservait déjà tout. Et il ne savait presque rien répondre.

Il y avait des milliers de fichiers PDF dans le stockage — contrats, factures, justificatifs, procès-verbaux, politiques, attestations — et le contenu de ces fichiers était, pour le système, une tache floue. Il y avait aussi autre chose, que je considère plus précieux : 53 colonnes de texte rédigé, dispersées dans la base. Le compte rendu d’une rencontre. Le programme d’un atelier. La clause d’un contrat. La trace de ce qui s’est réellement passé, écrite par des membres de l’équipe — et hors d’atteinte de toute recherche.

Parce qu’il n’existait pas de recherche. Le Cockpit avait trois recherches séparées, une par module, et chacune ne connaissait que son propre coin. Demander « où est la clause de résiliation du contrat avec ce fournisseur ? », c’était ouvrir des dossiers.

La première trouvaille : trois des quatre « nous n’avons pas » existaient déjà

Nous avons commencé par lister ce qui manquait. Il y avait quatre choses. Trois ne manquaient pas.

La technologie de recherche par le sens était déjà installée sur le serveur et n’avait jamais été activée — il manquait une commande d’une ligne. Le programme qui lit le texte à l’intérieur d’un PDF (y compris par reconnaissance de caractères sur un document numérisé) tournait déjà en production et jetait le résultat à la poubelle à la fin de chaque requête. Et la norme permettant d’enregistrer d’où venait une donnée produite par l’IA existait déjà, en état de marche, dans un coin du système.

Avec les noms, pour qui voudrait vérifier : la recherche par le sens, c’est l’extension pgvector, déjà installée sur le serveur et à laquelle il ne manquait qu’une commande CREATE EXTENSION vector. La lecture de PDF, c’est poppler, Tesseract, OCRmyPDF et Ghostscript — quatre programmes libres qui voyageaient déjà dans notre image de conteneur, appelés le temps d’une requête ponctuelle puis jetés. Et la provenance, c’était une table de diligence qui conservait déjà, pour chaque résultat, le modèle utilisé, la version de l’invite et une empreinte du contenu analysé. Aucune des trois n’a eu à être achetée, contractée ni inventée. Il a fallu les remarquer.

Trois des quatre « nous n’avons pas » étaient en réalité des « nous avons et nous ne nous en servons pas ».

C’est le premier enseignement que je veux consigner, car il vaut pour presque tout le monde : l’essentiel de ce qu’on appelle un « projet d’IA » dans une organisation est un travail de préparation des données que personne n’avait encore fait. L’inventaire nous a coûté quelques heures et a changé la conception du projet tout entier. Le travail a cessé d’être « construire » pour devenir « conserver ce qui était déjà produit puis jeté ».

Partie 2 — Ce que nous avons fait, en huit étapes

Nous avons organisé le travail en huit étapes numérotées, et l’ordre entre elles est la partie la plus importante — plus importante que n’importe quel choix technologique.

Oui, l’étape 4 vient avant la 3 dans la liste. Nous avons inversé l’ordre en cours de route, pour trois raisons mesurées. Je m’explique plus loin.

Les pièces, et pourquoi elles sont toutes libres

Avant les étapes, la liste de ce que nous utilisons. Elle vient ici plutôt qu’à la fin parce que « avec quoi ? » est souvent la première question — et parce que la réponse est moins impressionnante qu’on ne l’attend, ce qui est précisément le propos.

• PostgreSQL 16 — la base où les données du Cockpit vivaient déjà. Tout ce que je décris ci-dessous y habite. Nous n’avons monté aucune base nouvelle.
• pgvector — l’extension de Postgres qui stocke et compare des vecteurs. C’est la pièce « recherche par le sens ».
• unaccent et la recherche textuelle native de Postgres — ce qui fait que « prestacao » trouve « prestação ».
• poppler, Tesseract 5 avec le paquet portugais, OCRmyPDF et Ghostscript — la lecture de PDF et la reconnaissance de caractères, le tout dans notre propre machine.
• Rust, avec axum qui sert l’API et sqlx qui parle à la base — c’est le langage dans lequel le Cockpit est écrit.
• calamine, zip et quick-xml — des bibliothèques qui lisent .docx, .xlsx, .pptx et .odt. Elles étaient déjà déclarées dans le projet ; se mettre à les utiliser n’a coûté aucune dépendance nouvelle.
• multilingual-e5-small — le modèle qui convertit le texte en vecteurs. Il tourne en local, a 384 dimensions et tient sur une machine modeste.
• MCP (Model Context Protocol) — le standard ouvert par lequel un assistant d’IA dialogue avec un système. C’est l’étape 5, et j’y reviens posément.
• pgBackRest — la sauvegarde de la base, qui s’est mise à couvrir toute cette couche nouvelle sans une ligne de configuration supplémentaire, parce qu’elle habite dans Postgres.

Aucun élément de cette liste n’est cher, secret ou d’accès restreint. Tout est du logiciel libre, à la documentation publique, installable dès aujourd’hui par n’importe quelle organisation — et la plus grande partie était déjà sur notre machine avant le début du projet. La rareté, dans notre champ, n’est pas celle de la technologie. C’est celle du temps pour ranger les données. C’est pourquoi ce texte insiste sur l’ordre des étapes et non sur le choix des pièces.

Étape 0 — L’étalon avant la course

La première étape tenait en deux lignes de code et une tâche qui a consommé tout le temps : constituer un jeu d’évaluation. Ce sont 42 questions en langue naturelle, chacune accompagnée de la réponse, du document et de la page qui la prouvent.

Trois décisions qui ressemblent à des détails et n’en sont pas :

• L’étalon vient avant la recherche. Qui écrit les questions après avoir vu ce que le système trouve écrit les questions auxquelles le système répond juste. C’est un auto-aveuglement déguisé en méthode.
• Les questions sont écrites avec des mots différents de ceux du document, à dessein. Cela fait chuter le résultat — et c’est le seul moyen pour que le chiffre signifie « question posée par une vraie personne ».
• La page fait partie de la cible, pas seulement le document. C’est ce choix qui a révélé, deux étapes plus tard, que notre vrai problème était de trouver la bonne page. Un test qui n’aurait exigé que le document ne l’aurait jamais montré.

Et une décision de prudence : aucune question du jeu n’utilise de donnée personnelle. Notre fonds contient des pièces d’identité, des numéros de CPF et des noms de parents, et une grande partie de nos participants sont adolescents. Le jeu a été constitué uniquement à partir de documents institutionnels — statuts, procès-verbaux, bilans, politiques. Deux pages qui auraient fait de bonnes questions ont été écartées parce qu’elles portaient un RG et un CPF dans le corps du texte. La raison n’est pas seulement la confidentialité : un fichier de test se copie et se colle avec beaucoup plus de liberté que la donnée d’origine n’en a jamais eu.

Étape 1 — Le texte que nous jetions à la poubelle tous les jours

Cette étape n’utilise l’intelligence artificielle d’aucun fournisseur. Ce sont des programmes qui étaient déjà dans notre système : l’un lit le texte à l’intérieur du PDF, un autre reconnaît les caractères quand la page est une photo de papier, un autre tranche entre les deux.

Avec les noms : pdftotext, de poppler, tente en premier, parce qu’un PDF né numérique porte déjà son texte et que le lire coûte des millisecondes. Ce n’est que si une page passe sous un seuil de caractères utiles qu’elle est rastérisée et envoyée à Tesseract 5 avec le paquet portugais, orchestré par OCRmyPDF. Cet ordre — le bon marché d’abord, le coûteux seulement si nécessaire — est ce qui a séparé des heures de plusieurs jours lors de la reprise initiale : l’ancien moteur envoyait tout le monde à la reconnaissance de caractères, y compris les PDF qui n’en avaient pas besoin.

Et une précision honnête, puisque je passe tout ce texte à séparer « IA » et « pas IA » : Tesseract 5 est un réseau de neurones. Quand je dis que cette étape n’utilise aucune IA de fournisseur, je parle de fournisseur — aucun appel d’API, aucune clé, aucun octet qui sorte — et non de « aucun réseau de neurones impliqué ».

Aucun PDF ne sort de la Casa Hacker. Ni vers un service de reconnaissance de texte, ni vers un service de « lecture de document », en aucun cas. Cela a été décidé avant la moindre ligne de code et n’a jamais été rouvert.

Trois choix techniques qui méritent d’être traduits :

L’unité est la page. Stocker le document entier dans un champ de texte aurait été plus simple et aurait détruit le produit. « J’ai trouvé le contrat » sans « c’est à la page 3 » ne sert à rien pour la reddition de comptes — et la reddition de comptes, c’est ce qui paie les factures ici. Aujourd’hui, quand la recherche trouve quelque chose, elle ouvre le PDF à la page exacte.

Le document est identifié par son contenu, pas par son nom. Chaque fichier a une « empreinte » calculée à partir de ce qu’il contient — un sha256, la même somme de contrôle qu’une distribution Linux publie à côté du fichier que vous téléchargez. Les fichiers identiques ont la même empreinte, ils ne sont donc lus qu’une seule fois. Nous avons découvert qu’environ 18 % de notre fonds sont des doublons — le même justificatif joint à deux endroits.

La file d’attente est une table, pas un service de messagerie. Un document en attente, c’est une ligne à l’état pendente, et un balayage périodique cherche ce qui est resté en arrière. Nous aurions pu monter un RabbitMQ ou un Redis. Nous ne l’avons pas fait : une table dans une base qui existe déjà est couverte par la sauvegarde qui existe déjà, survit à un redémarrage sans la moindre configuration et ne devient pas un service de plus pour lequel réveiller quelqu’un la nuit. Et surtout, le balayage couvre tout par construction — y compris les fichiers qui arrivent par des chemins qui ne passent pas par l’écran d’envoi, comme le collecteur automatique de factures. Un déclencheur à l’envoi ne couvrirait que ceux qui préviennent ; le balayage couvre aussi ceux qui ne préviennent pas.

Et la partie dont je suis le plus fier : une lacune énoncée est une lacune ; une lacune cachée est un mensonge. Aujourd’hui, 3 858 documents sont marqués « format non pris en charge » et 94 comme « erreur » — PDF chiffré, fichier corrompu, format sans lecteur. Ils apparaissent nommés à l’écran, comptés. Parce qu’un index qui cache ce qu’il n’a pas su lire produit un « je n’ai pas trouvé » que la personne lit comme « ça n’existe pas » — et c’est la pire réponse possible dans un système de gestion, parce qu’elle est identique à une bonne réponse.

Étape 2 — La première recherche de notre histoire, et la découverte que personne n’attendait

La partie facile a été celle qu’on attendait : une recherche en portugais, sans exiger les accents, répondant en millisecondes. Chercher « prestacao de contas » trouve « prestação de contas ».

C’est la recherche textuelle native de PostgreSQL, sans aucun service de recherche à part. Quatre pièces, toutes d’origine : une configuration de langue à nous, qui joint le dictionnaire portugais de la base à l’extension unaccent ; une colonne qui se tient à jour toute seule avec le texte déjà préparé pour la recherche ; un index GIN par-dessus ; et ts_headline, qui renvoie l’extrait avec le terme surligné. Nous n’avons pas installé Elasticsearch, ni OpenSearch, ni monté un second serveur. Je reviens sur ce refus dans les règles, car ce n’était pas une économie — c’était du contrôle d’accès.

Le premier résultat honnête a été 2 bonnes réponses sur 28 questions.

En enquêtant, nous avons trouvé la raison, et elle est belle : le moteur de recherche de notre base de données ne sait pas ce qui est rare. Il pèse le nombre de fois où le mot apparaît à l’intérieur du document et ignore s’il apparaît partout. Dans notre fonds, « casa » apparaissait sur la moitié des pages, « atividade » et « projeto » sur près de la moitié — et le système donnait à ces mots le même poids qu’à « bolsa incentivo ». Ce n’était pas un problème de configuration. C’était l’absence d’un signal dont la documentation ne prévient pas qu’il est absent.

Cela porte un nom, dans la littérature de la recherche d’information : la fréquence inverse de document — l’« IDF » que les moteurs de recherche dédiés offrent d’origine depuis des décennies, et que la recherche textuelle de Postgres ne calcule tout simplement pas. Nous avons donc construit la nôtre : une table de rareté des mots, montée à partir d’une fonction que la base offre déjà (ts_stat), prête en neuf secondes, comptant aujourd’hui 323 776 radicaux qui indiquent le poids réel de chaque terme. Avec cela, 2 sur 28 sont devenus 14 sur 32.

Et c’est là qu’est venue la plus grande leçon. Une question contenait le mot « gitlab », présent sur une seule page sur 35 mille — l’identifiant parfait. Le bon document arrivait en position 155. Raison : trois mots moyens additionnés l’emportaient sur le mot unique. La somme diluait précisément le signal le plus fort.

La correction a tenu en une ligne : classer d’abord par le mot le plus rare que contient la page, et n’utiliser la somme que pour départager. Nous avons testé les variantes évidentes avant de retenir celle-là — sommer le carré des poids, doubler le plus grand et ajouter le reste, classer par le nombre de termes couverts par la page. Toutes mesurées, toutes moins bonnes. Celle qui a gagné et les trois qui ont perdu sont consignées dans le code, chacune avec son chiffre. Résultat final, après trois corrections de ce type :

• document dans les 10 premiers : de 2 à 19 sur 34 questions
• bonne page dans les 10 premières : 14 sur 34
• questions comportant une faute de frappe : de 3 sur 6 à 6 sur 6
• temps de réponse : de 177 millisecondes à 11

Une ligne de classement a rapporté plus que toute la couche d’intelligence artificielle. J’y reviens à l’étape 3.

Étape 4 — Le dictionnaire : la différence entre la date du fait et la date du tampon

Chercher des passages répond à « où est-ce écrit ». Cela ne répond ni à « combien avons-nous dépensé » ni à « combien de jeunes avons-nous accueillis ». Ces questions-là viennent d’une requête à la base — et pour réussir cette requête, il faut savoir ce que signifie chaque champ.

C’est pour cela que nous avons construit un catalogue de données : la description lisible de ce que veulent dire chaque table et chaque colonne. Il est généré automatiquement à partir de la base elle-même et vérifié à chaque changement de code. Un catalogue tenu à la main pourrit en quelques semaines et se met à mentir — ce qui est pire que de ne pas exister.

Le mécanisme est modeste et mérite d’être copié. La base sait déjà se décrire elle-même : Postgres tient un inventaire de ses propres tables et colonnes (information_schema) et un endroit où chacune peut porter un commentaire (COMMENT ON, qui vit dans pg_description). Un programme lit les deux et écrit des fichiers de catalogue dans le dépôt. Ce qui transforme cela en documentation vivante, c’est l’étape suivante : un test d’intégration continue qui rejette la modification si le catalogue versionné diverge de la base. Sans ce test, c’est un document de plus ; avec lui, qui touche à la base sans décrire ce qu’il a touché n’arrive pas à intégrer. Au-delà des tables, le catalogue couvre les routes de l’API et les tâches planifiées — et le catalogue de routes s’est révélé utile d’une manière que nous n’avions pas prévue, à l’étape 7.

Le champ le plus important de ce catalogue est celui qui sépare la date du fait de la date du tampon. Laissez-moi raconter le cas concret, car il explique tout :

Il existait une colonne appelée data_inscricao. On dirait la date à laquelle la personne s’est inscrite. Nous avons mesuré : dans 978 enregistrements sur 978, elle contenait le jour où la donnée avait été importée d’un autre système. Une colonne sœur, mesurée ensuite, avait 98,9 % de ses enregistrements concentrés sur deux jours.

Qui regroupe par ces colonnes produit une courbe de croissance qui semble juste, est fausse, et se présente avec assurance — parce que la requête s’est exécutée sans la moindre erreur. Aucun test automatique n’attrape cela. Seul le dictionnaire l’attrape. Nous avons reconstruit la colonne à partir de la vraie source, et le catalogue porte aujourd’hui la consigne explicite : ne regroupez pas ceci pour une série temporelle.

Le catalogue mesure aussi sa propre honnêteté : sur les 4 807 colonnes cataloguées, seules 232 (4,8 %) ont une description rédigée. Le générateur imprime ce chiffre à chaque passage, précisément pour qu’il soit exigé et non estimé.

Quand nous avons comparé les réponses d’un assistant à des questions sur nos données, avec et sans le catalogue : 17 sur 19 sans, 18 sur 19 avec. Le gain au tableau est mince. Mais dans 8 des 19 cas, le catalogue a changé la substance de la réponse même lorsque le chiffre était déjà juste — l’assistant s’est mis à distinguer trois tables différentes appelées « projeto », à savoir qu’une date était un tampon, à savoir que le texte extrait contient des données personnelles.

Étape 3 — La partie « IA » que nous avons construite et laissée de côté

C’est l’étape que la plupart des projets font en premier. Nous l’avons faite en dernier parmi les étapes de préparation, et délibérément : sans point de référence, on ne peut pas affirmer que l’IA a amélioré quoi que ce soit, seulement le croire.

Le mécanisme, en clair : le texte est découpé en passages, et chaque passage est converti en une liste de nombres qui représente son sens. Les passages de sens voisin se retrouvent proches. Cela permet de chercher par le sens, et non par le mot exact. Nous avons aujourd’hui 77 068 passages convertis.

Avec les noms : le découpage en passages est du code à nous, sans bibliothèque — des paragraphes allant jusqu’à deux mille caractères, avec un morceau de recouvrement entre voisins, et jamais à cheval d’un document sur un autre. Le modèle qui convertit un passage en nombres est multilingual-e5-small, 384 dimensions, tournant en local au format ONNX : aucun passage n’a été envoyé à un fournisseur quelconque, ce qui maintient la règle de l’étape 1. Les vecteurs sont dans pgvector, à l’intérieur de la même base, avec un index HNSW — la structure qui permet de trouver les voisins les plus proches sans les comparer à tous.

Le résultat de la mesure a été inconfortable et c’est le résultat le plus précieux du projet :

Toute la couche d’intelligence artificielle — 44 mille vecteurs, 167 mégaoctets, 83 minutes de traitement, un nouveau composant dans le système — a rapporté un document de plus sur notre jeu de questions. Une ligne de classement dans la recherche par mot en a rapporté deux, et trois pages.

Et pire : la technique consacrée qui consiste à combiner les deux recherches a dégradé le résultat, de 15 à 13. Elle porte un nom — la fusion réciproque des rangs, ou RRF, la recette standard pour marier recherche par mot et recherche vectorielle — et la raison de l’échec est arithmétique, ce n’est pas une opinion : la formule additionne l’inverse de la position dans chaque liste, ce qui récompense le document médiocre dans les deux face à l’excellent dans une seule. Sur les questions comportant un numéro de contrat, où la recherche par mot plaçait le document en première position, la combinaison a fait tomber cette première place. C’est une bonne technique, publiée, largement recommandée — et fausse pour notre fonds, qui est plein d’identifiants. Seule la mesure pouvait le dire.

Nous avons donc gardé les vecteurs chargés et hors de la recherche. Ils servent aujourd’hui à trois choses utiles, toutes mesurées :

• Documents similaires. Pour chaque document, les huit plus proches du fonds. Un acte de donation a désigné comme voisin un autre acte fondé sur le même modèle, en un dixième de seconde.
• Quasi-doublons. 35 550 paires. Utile pour le ménage du fonds : deux attestations du même fournisseur, deux envois du même justificatif.
• Tri. Un document sans classement reçoit une suggestion de type via ses voisins, qu’une personne confirme d’un clic.

Un effet secondaire devenu tâche à part entière : l’écran des quasi-doublons mettait 25,8 secondes. Il manquait un index dans la base sur la colonne de l’empreinte — quatre lignes de migration. Il est passé à 0,36 seconde. Une couche nouvelle posée sur un vieux système révèle ce qui dormait.

Étapes 5, 6 et 7 — L’assistant entre par la porte d’entrée

C’est ici que l’IA entre enfin, et la question qui nous a guidés était : comment un assistant peut-il travailler avec nos données sans enfreindre aucune de nos règles d’accès ?

Cette porte a un nom : MCP, le Model Context Protocol. C’est un standard ouvert, publié par Anthropic fin 2024 et aujourd’hui parlé par plus d’un fabricant d’assistants, qui définit comment une IA découvre et utilise les outils d’un système extérieur. Avant lui, brancher un assistant sur un système supposait d’écrire une intégration sur mesure pour chaque assistant. Avec lui, le système publie ses outils une fois, et n’importe quel client qui parle le protocole les trouve tout seul.

Notre serveur MCP est construit et en service. Ce n’est ni un plan ni un prototype : 86 outils publiés sur les 13 modules du Cockpit, et la preuve a été faite contre le système en production — le client demande la liste des outils et reçoit les 86 ; il exécute une lecture et reçoit la réponse que donnerait l’écran ; il demande un essai d’écriture et reçoit l’effet prévu sans que rien ne se produise ; et, lorsqu’il demande ce que sa portée ne couvre pas, il reçoit un 403 nommant exactement l’autorisation qui manquait.

Et c’est cela qui donne son sens aux sept étapes précédentes : le fonds a cessé d’être un dépôt pour devenir atteignable. Les 24 549 documents, les 60 702 pages de texte, les 53 colonnes de prose écrites par notre équipe, le catalogue qui dit ce que signifie chaque champ et les 13 modules du système sont, aujourd’hui, à la portée d’un assistant d’IA — par la même porte et avec les mêmes autorisations qu’une personne. Une éducatrice peut demander en portugais où se trouve la clause d’un contrat et recevoir le document et la page. Qui s’occupe de la reddition de comptes demande le justificatif d’un paiement sans ouvrir le moindre dossier. Et rien de tout cela n’a exigé d’ouvrir la base de données à l’IA, d’envoyer un document à l’extérieur ni d’accorder à quiconque une autorisation qu’il n’avait pas déjà.

Pour une organisation de notre taille, c’est la partie dont j’ignorais si nous y arriverions. Un serveur MCP en production, ce n’est pas ce qu’on attend d’une organisation de la société civile de la périphérie, tournant sur huit cœurs de calcul, sans équipe de plateforme. Nous y sommes arrivés — et nous y sommes arrivés parce que nous n’avons pas commencé par là. Il a fallu avoir le texte conservé (étape 1), une recherche qui fonctionne (étape 2), un catalogue qui explique les données (étape 4) et des vecteurs mesurés (étape 3) pour qu’ouvrir la porte de l’étape 5 en vaille la peine. Qui ouvre cette porte en premier livre à l’assistant un fonds qu’il n’arrive pas à lire, sur une base qu’il ne sait pas interpréter. La porte est la partie facile. Ce qui en fait une porte utile, c’est tout ce qui vient avant.

Ce qui a permis d’y arriver sans enfreindre la moindre règle d’accès tient en trois parties.

Peu d’outils nommés, jamais d’accès libre à la base. Nous avons commencé avec trois : chercher des documents, lire un document page par page, consulter le catalogue. Pas trente. La requête libre à la base est interdite par écrit. Un assistant en accès libre se trompe davantage, et se trompe en silence.

Une vraie authentification, pas un mot de passe collé dans un fichier. La personne clique sur « connecter » dans son assistant, est amenée au Cockpit, s’authentifie comme elle le ferait à l’écran, voit exactement ce qui est demandé et l’autorise. L’accès accordé est obligatoirement inférieur ou égal à celui qu’elle a déjà dans le système. Personne ne gagne de droits en connectant un assistant.

C’est OAuth 2.1 — le même standard du « se connecter avec » que tout le monde a déjà utilisé, et que la spécification MCP prévoit justement pour les serveurs distants comme le nôtre. L’alternative serait que chacun engendre un jeton et le colle dans un fichier de configuration, et la raison de notre refus est prosaïque : un jeton collé finit dans une conversation, dans un historique, dans une capture d’écran. Mais il y a une conséquence plus grande, de portée. Comme se connecter est devenu un clic, le serveur a pu être distribué à toute la maison sous forme de greffon Claude, et pas seulement à qui sait éditer un fichier de configuration. Cela change qui est le public — et c’est exactement pour cela que le masquage des données personnelles et l’attente calibrée, plus loin, cessent d’être un raffinement pour devenir une obligation. Une réponse fausse assénée avec conviction frappe de plein fouet celui qui n’a pas le bagage pour s’en méfier.

Chaque action classée selon ce qu’elle coûte. Aujourd’hui, ce sont 86 outils et 230 actions dans les 13 modules, et chacune a été classée en ouvrant le code, une par une — deux fois, par des équipes indépendantes, parce que le premier passage a laissé filer six cas :

• 118 actions réversibles — elles s’exécutent et restent enregistrées. Créer un ordre du jour, inscrire un membre.
• 29 actions ayant un effet vers l’extérieur — sans confirmation explicite, le système renvoie ce qui allait se produire et s’arrête. Envoyer un e-mail à quelqu’un, transmettre un contrat pour signature, toucher à un compte de l’organisation.
• 14 actions qui déplacent de l’argent ou du patrimoine — elles exigent une simulation préalable enregistrée et une confirmation humaine. Solder une facture, contrepasser une écriture, changer le responsable d’un équipement.

Nous aurions pu laisser les rouges de côté. Nous avons préféré l’inverse : elles entrent, obligées de montrer d’avance exactement ce qu’elles vont faire. Retirer l’action de la table cache le risque ; l’obliger à s’expliquer d’abord rend le risque auditable.

Il y a une décision d’architecture qui est peut-être la partie la plus réutilisable de tout ceci : les outils ne dialoguent pas avec la base — ils appellent les mêmes routes que l’écran. Quand quelqu’un demande à l’assistant d’enregistrer un membre, la demande est dépêchée en interne vers exactement la route qu’utiliserait le formulaire du Cockpit, en portant l’identité de qui a autorisé. La conséquence, c’est qu’aucune validation, aucune vérification d’autorisation et aucun enregistrement d’audit n’a eu à être réécrit pour l’IA : tout tourne par construction, parce que c’est le même code. L’alternative — réimplémenter les règles du côté de l’assistant — crée une seconde source de vérité, qui déraille le jour où quelqu’un change une règle à un seul endroit. C’est la même leçon que la règle 4, juste en dessous, appliquée à nouveau.

Et trois précautions qui existent à cause d’une différence simple : une personne clique une fois ; un assistant répète l’appel quand le réseau échoue.

• Clé d’idempotence. Toute écriture porte un identifiant de l’opération. Répéter l’appel renvoie le résultat du premier — cela ne crée pas une seconde facture à payer.
• Un essai avant l’action. Toute écriture sait répondre à « que se passerait-il si je faisais ceci », sans le faire. Pour les actions rouges, l’essai n’est pas facultatif : sans essai enregistré au préalable, l’exécution est refusée.
• Traçabilité. Chaque écriture enregistre qui a autorisé, quel agent a exécuté, quand, avec quelles données et avec quel résultat. Une action sans trace n’existe pas dans la conception.

C’est ici que le catalogue de l’étape 4 a remboursé son propre investissement d’une manière que nous n’avions pas prévue. Les 230 actions vivent dans un registre qui pointe, une à une, vers la route que chacune appelle — et un test d’intégration continue confronte ce registre au catalogue de routes à chaque modification. Une route renommée a cessé d’être ce qui casse l’assistant en production pour devenir ce qui rejette la modification avant qu’elle n’entre. La première exécution de ce test a trouvé six routes que le registre citait et qui n’existaient plus — et, derrière elles, un défaut dans le générateur du catalogue lui-même, désormais traité comme un défaut enregistré et non comme une curiosité.

Les cinq règles que nous n’avons pas négociées

Si ce texte doit servir à quelque chose au-delà de nos murs, j’espère que ce sera grâce à cette liste.

1. Aucun document ne sort de la maison. Toute lecture de PDF et toute reconnaissance de texte se font au sein de notre propre infrastructure. Nous en assumons le coût : le plafond de qualité devient celui de notre outil, sans plan B pour une numérisation médiocre.
2. L’autorisation appartient à la pièce jointe, jamais au contenu. Un même fichier peut être joint dans des contextes appartenant à des propriétaires différents. Si la recherche répondait par l’empreinte du fichier, quiconque a accès à une pièce jointe lirait le texte d’un autre contexte. La recherche renvoie la pièce jointe, et l’autorisation est tranchée avant d’atteindre le texte.
3. Masquage à la sortie, jamais au stockage. Quand un passage part vers un service externe, CPF, CNPJ, e-mail et téléphone sont remplacés, et l’on enregistre la quantité de données sorties. Conserver une seconde copie « propre » reviendrait à créer deux sources de vérité — et un texte masqué dans la base détruit la recherche, même pour ceux qui en ont le droit.
4. La recherche hérite du contrôle d’accès, elle ne le réimplémente pas. C’est la raison pour laquelle nous avons gardé la recherche par le sens à l’intérieur de notre propre base de données, plutôt que de recourir à un service séparé. Un index qui vit à l’extérieur ne sait pas qui peut voir quoi : soit il recopie nos règles d’autorisation — et il déraille le jour où quelqu’un change une règle à un seul endroit — soit il laisse fuir le juridique, les RH et les signalements. Nous avons envisagé une base vectorielle dédiée, et Qdrant en était le candidat ; nous l’avons refusée pour cette raison, non pour des questions de performance. Dans pgvector, filtrer selon ce que la personne peut voir est un JOIN ; en dehors, c’est une seconde copie de notre modèle d’autorisations. Pour la même raison, nous n’avons pas monté Elasticsearch pour la recherche par mot. Et nous avons écrit ce qui nous ferait changer d’avis : dépasser cinq millions de passages, ou une recherche de voisinage qui prendrait plus de 300 millisecondes, ou l’apparition d’un vrai besoin d’isoler des fonds dans des index séparés. Une décision sans critère de révision est de l’entêtement à date fixe.
5. Toute réponse cite la page. Sans citation vérifiable, la réponse n’est que la parole de l’IA. Et la parole de l’IA ne rend de comptes à aucun financeur.

Ce que nous avons aujourd’hui, en chiffres

Tout a été mesuré le jour où ce texte a été écrit, sur le système en production :

• 30 099 pièces jointes, 24 549 contenus distincts, 21 729 PDF
• 60 702 pages de texte conservées, 171,7 millions de caractères
• 4 326 pages ayant exigé une reconnaissance de caractères
• 5 333 textes provenant de champs rédigés par des membres de l’équipe
• 323 776 mots dans la table de rareté
• 77 068 passages convertis en vecteurs
• 44 164 vecteurs de 384 dimensions, produits par un modèle qui tourne sur notre machine
• 1 204 routes d’API cataloguées — 837 combinaisons de route et de méthode servent à lire, 1 392 à écrire
• 86 outils d’IA publiés par le MCP, 230 actions classées
• et le serveur où tout cela tourne a 8 cœurs de traitement

Ce dernier chiffre n’est pas une anecdote, c’est le principal fait d’ingénierie de ce projet. Nous ne sommes pas une entreprise technologique dotée d’un nuage infini. Le grand chantier initial de lecture des documents a tourné sur une machine louée à l’heure et détruite à la fin, avec une permission en lecture seule, sans ouvrir un seul nouveau port en production. Depuis, le traitement quotidien tourne en production avec un unique processus et un plafond par passage.

Et une preuve que la conception tient : entre la première mesure et aujourd’hui, notre fonds a plus que doublé — parce que l’export intégral d’un système comptable que nous allons éteindre est arrivé. La conception a absorbé cela sans la moindre modification. Un processus qui ne fonctionne qu’au volume pour lequel il a été construit n’est pas un processus.

Partie 3 — Maintenant, oui : les questions que nous voulons poser

Une fois toute la base de données réunie, nous avons commencé à nous demander : qu’est-ce qui peut en sortir ? Quelles réponses le contexte et le croisement sécurisé de ces informations pourraient-ils nous révéler ?

Nous avons pas mal spéculé. L’une des idées a été de réfléchir à la façon dont l’intelligence artificielle pourrait nous aider à mener une analyse prédictive à partir du parcours d’une jeune fille qui entre dans l’un de nos programmes — c’est-à-dire à utiliser l’historique de celles et ceux qui sont déjà passés par ici pour estimer ce qui peut arriver à celles qui arrivent. En regardant l’histoire de la Casa Hacker et les jeunes qui ont déjà décroché, que pourraient nous révéler ces données, traitées avec tout le soin nécessaire, sur cette nouvelle arrivante ? En quoi cela pourrait-il nous aider à mieux accueillir quelqu’un dont la probabilité de décrochage est plus élevée ?

Voici quelques exemples concrets de ce que nous aimerions parvenir à voir :

• Les membres d’une zone précise arrivent-ils plus souvent en retard à cause de problèmes urbains du territoire — rues non goudronnées, inondations récurrentes les jours de pluie ?
• Les membres d’un quartier donné présentent-ils davantage de problèmes respiratoires par manque d’infrastructures ? Et pourrions-nous, à partir de là, assurer un suivi plus rapproché avec les familles avant que cela ne devienne une absence récurrente, puis un décrochage ?
• Les jeunes qui déménagent fréquemment ont-ils un risque d’abandon plus élevé dans les premiers mois ?
• Existe-t-il un schéma de désengagement silencieux — une assiduité qui décline peu à peu, sans une absence isolée qui attire l’attention, mais visible sur une série historique ?
• Les horaires où les absences sont les plus nombreuses coïncident-ils avec la distance jusqu’aux transports en commun pour certaines familles ?
• Y a-t-il des mois de l’année — période d’inscription scolaire, saison de travail informel des responsables — où le décrochage devient plus probable ?
• En regardant les frères, sœurs ou proches déjà passés par la Casa Hacker, existe-t-il un schéma familial que nous pourrions anticiper ?

Et il y a un second groupe de questions, plus ambitieuses, auxquelles on ne peut répondre qu’en croisant nos données avec le bulletin scolaire et avec des bases publiques :

• Les jeunes dont les résultats baissent dans une matière précise dans les deux mois précédant leur entrée dans un programme de technologie abandonnent-ils plus tôt ? Cela permettrait un soutien pédagogique ciblé avant que le décrochage n’apparaisse dans nos relevés de présence.
• En croisant le revenu familial déclaré avec l’assiduité, peut-on repérer si les jeunes des familles les plus vulnérables s’absentent davantage à certaines périodes du mois — indiquant le bon moment pour une bourse ou une aide au transport ?
• Les jeunes ayant déjà redoublé ont-ils besoin d’un parcours d’accueil pédagogique différent dès le premier mois ?
• Croiser la composition familiale et les absences peut révéler si des responsabilités de soin domestique — qui pèsent bien plus souvent sur les filles — expliquent des absences qui, à première vue, passeraient pour du désintérêt. Cette seule hypothèse justifierait l’effort.
• Les jeunes issus d’établissements à fort renouvellement d’enseignants (donnée publique du recensement scolaire) ont-ils plus de mal à s’adapter, ce qui suggérerait un soutien de remise à niveau ?
• Les jeunes qui habitent plus loin, même avec des résultats scolaires stables, décrochent-ils davantage en période de hausse des tarifs de transport — chose qui n’apparaît qu’en croisant la donnée géographique et le calendrier économique ?
• Et, parmi celles et ceux qui ont terminé les programmes avec succès, existe-t-il un profil récurrent ? Une carte des facteurs de protection, et pas seulement des facteurs de risque ?

J’avoue croire que c’est exactement là que l’intelligence artificielle devrait agir : en nous montrant, à partir de l’histoire et des données accumulées, comment mieux accueillir chaque personne, et en repérant des motifs que notre seule capacité humaine aurait bien du mal à voir.

Nous n’attendons pas de l’IA qu’elle fasse des choses triviales à notre place, comme lire et répondre à nos e-mails — cela ne nous intéresse pas. Ce qui nous intéresse, c’est : comment aller plus loin ? Comment mieux recevoir les gens ? Comment repérer les risques avant qu’ils ne surviennent — non pour exclure qui que ce soit, mais pour accueillir avec plus de soin ? Si l’intelligence artificielle ne sert pas à cela à un moment donné, j’ai le sentiment que nous aurons échoué.

Ce que l’étalon dit de notre propre ambition

Si ce projet m’a appris une chose, c’est à mesurer avant d’affirmer. J’ai donc appliqué le même étalon à ma propre ambition, et le résultat mérite d’être publié.

Ce que nous avons déjà :

• 1 210 membres inscrits, 2 756 inscriptions à 216 activités
• 24 309 relevés de présence sur 2 083 rencontres, de juin 2022 à aujourd’hui
• 928 membres avec une présence enregistrée, dont 733 avec cinq relevés ou plus — c’est-à-dire avec une série suffisante pour tracer une courbe
• 3 509 fiches de suivi individuel
• une adresse exploitable pour 921 des 1 210 membres (76 %), ce qui rend le croisement territorial possible pour trois sur quatre

La limite que nous nous sommes imposée

Cela doit être écrit, parce qu’il s’agit d’enfants et d’adolescents.

Parmi nos membres dont la date de naissance est enregistrée, 376 ont moins de 18 ans. Attribuer une « note de risque de décrochage » à un adolescent n’est pas un acte neutre, et un système qui ferait cela sans garde-fous devient très vite une machine à étiqueter les jeunes des périphéries. Nous avons déjà vu ce film dans le crédit, dans la sécurité publique et dans l’éducation.

Nos garde-fous, donc :

• La prédiction ne devient jamais la note du jeune. Elle devient, tout au plus, une invitation à une conversation et un signal pour l’équipe pédagogique. Jamais un critère d’entrée, de maintien ou de sélection.
• Jamais pour exclure ; toujours pour accueillir. Si un jour un chiffre de ce système sert à retirer quelqu’un d’un programme, le système a échoué et doit être éteint.
• C’est la personne qui décide, toujours. La machine prépare, met en évidence et cite. Celle qui décide est l’éducatrice qui connaît cette famille. Ce n’est pas de la diplomatie — c’est la conception technique : chaque action importante de l’assistant exige une confirmation humaine.
• Facteur de protection, et pas seulement facteur de risque. La question « qu’est-ce qui marche avec celles et ceux qui terminent ? » est plus utile, et moins dangereuse, que « qui va abandonner ? ».
• Donnée de santé uniquement avec autorisation explicite, et donnée du responsable légal avec une base légale claire. Nous sommes régis par la LGPD et nous traitons cela comme une contrainte de conception, non comme une clause en bas de page.
• Aucun document et aucune donnée personnelle identifiable ne part vers un service externe sans passer par le masquage décrit plus haut.

Mieux communiquer avec celles et ceux qui investissent

Il y a un point aussi important que les précédents : comment l’intelligence artificielle peut nous aider à mieux communiquer avec nos financeurs, à produire des données de meilleure qualité et plus auditables, à donner plus de transparence sur nos dépenses, en montrant plus intelligemment comment nous fonctionnons au quotidien à celles et ceux qui investissent avec nous.

C’est la partie qui a déjà changé concrètement, et elle a changé parce que la préparation a été faite dans le bon ordre. La quasi-totalité de nos recettes est constituée de fonds fléchés — projets d’incitation fiscale, dons affectés, appels à projets — et chaque dépense est justifiée document par document. Ce qui relevait de l’archéologie dans des dossiers est aujourd’hui une recherche qui renvoie le document et la page, en millisecondes, en respectant qui peut voir quoi. Le justificatif en double apparaît comme une paire, et non comme une découverte accidentelle lors de la vérification de la veille de l’échéance.

Et il y a une conséquence économique directe : d’ici 2027, nous prévoyons d’éteindre sept plateformes propriétaires que nous payons aujourd’hui par abonnement. Nous échangeons une licence récurrente et un contrat de traitement de données fragile contre un fonds documentaire qui nous appartient, auditable et sous notre responsabilité.

Pourquoi nous racontons cela

Parce que la méthode est la partie qui sert à d’autres organisations, et c’est le résultat de long terme que nous avons inscrit dans notre propre planification : une méthode de préparation des données, documentée et reproductible par d’autres organisations de la société civile.

Aucune organisation de notre champ n’a de nuage infini. Presque toutes ont un fonds documentaire important et une petite équipe. Ce qui se transmet d’ici, ce n’est pas du code — c’est l’ordre des étapes et l’habitude de mesurer avant de décider. Et il vaut la peine d’insister sur un point que la liste des pièces plus haut disait déjà sans tapage : il n’y a dans cette architecture aucun composant payant, propriétaire ou d’accès restreint. Postgres, pgvector, unaccent, poppler, Tesseract, OCRmyPDF, un modèle d’embeddings ouvert et un protocole ouvert. Ce qui a coûté, ce ne sont pas des licences — c’est de décider l’ordre, d’écrire l’étalon et d’accepter ce qu’il a répondu. En huit étapes, six de nos hypothèses plausibles ont été démenties par la mesure : augmenter la résolution de la numérisation (dégrade), nettoyer l’image avant la lecture (détruit 28 % des caractères), combiner les deux recherches (dégrade), afficher une page par document (dégrade la précision de la page). Chaque réfutation est écrite dans le code, avec le chiffre, à l’endroit précis où quelqu’un tenterait de recommencer.

La valeur la moins chère que produit une mesure n’est pas de découvrir quoi faire. C’est d’empêcher trois changements qui ressemblaient à des améliorations.

Nous disons que les périphéries ne sont pas un lieu d’attente, mais un lieu de commencement. Cela vaut aussi pour notre rapport à la technologie : nous n’attendons pas qu’une grande solution d’intelligence artificielle arrive du dehors, toute prête pour notre réalité. Le basculement ne vient pas de l’extérieur. Nous mettons de l’ordre dans la maison pour que, le jour où elle servira, elle serve vraiment — à accueillir des gens, et non à nous donner de jolies réponses sur des données que nous ne comprenions pas.

Voilà quelques-uns des défis qui, je crois, doivent nous guider comme raison d’être.

Le compte rendu technique complet de ce travail, avec toutes les mesures, les décisions d’architecture et le glossaire des termes employés ici, est publié sous forme de whitepaper. Le jeu de 42 questions qui nous sert d’étalon est versionné et peut être exécuté par n’importe qui — il a été conçu exprès pour qu’une autre organisation puisse répéter la mesure sur son propre fonds.