Un citoyen pousse la porte d'un guichet. L'agent tape quelques mots pour retrouver la consigne applicable à son dossier. Le document qui s'affiche à l'écran date de trois ans. Personne dans la pièce ne le sait, et pourtant la décision prise ce matin s'appuie dessus.
Voilà à quoi ressemble, dans la vraie vie, ce que beaucoup d'administrations appellent déjà « leur base de connaissances ». On a numérisé des armoires, on a empilé des fichiers dans un disque partagé, et on en a conclu que le problème était réglé. C'est probablement le malentendu le plus coûteux de tout le secteur public : confondre un classeur numérique avec une mémoire utilisable.
La difficulté n'a jamais été de tout stocker. Les administrations savent entasser. Ce qui se dérobe, c'est la capacité à retrouver le bon bout de papier, à l'instant T, et à oser s'y fier pour agir. Les fichiers s'accumulent ; la part de ce qu'on peut invoquer sans hésiter rétrécit. À bien y penser, traiter ces systèmes de « bases de connaissances » est un compliment qu'ils ne méritent pas. Appelons-les plutôt ce qu'ils sont : de vastes placards.
Quand le volume explose, la recherche s'effondre
Regardez ce chiffre, il devrait vous donner froid dans le dos. Plus de 3 000 milliards de fichiers PDF circulent déjà dans le monde, et sur une seule grande plateforme de collaboration, plus de 2 milliards de fichiers sont téléversés chaque jour. Les systèmes publics ne font pas exception : ils sont pires. Courriers officiels, procès-verbaux, dossiers d'instruction, plans, enregistrements audio et vidéo — des formats hétéroclites, des versions à n'en plus finir, des durées de conservation qui se comptent en décennies. Le volume a grimpé. La trouvabilité, elle, a pris du retard.
Une enquête mondiale commandée par M-Files à Vanson Bourne a capté cette souffrance avec une précision chirurgicale : 96 % des salariés déclarent peiner à retrouver la dernière version d'un document, et 83 % ont déjà recréé un fichier de toutes pièces simplement parce qu'ils ne trouvaient pas celui qui existait déjà. Transposez cela dans un contexte administratif et le vertige monte d'un cran. Une même note d'interprétation peut être enregistrée sous une forme légèrement différente par plusieurs services, et personne n'est sûr de savoir laquelle est « en vigueur ». Le citoyen débarque, l'agent ouvre un texte vieux de trois ans. Cette lente dérive vers le chaos blesse davantage qu'une quelconque pénurie de disques durs.
Le plus ironique ? La solution n'est presque jamais « acheter davantage de capacité ».
Une approche qui tient la route sur le terrain
UglyPear Data a rassemblé la « compression × socle d'ingénierie de données RAG » en un déploiement qui peut tourner intégralement sur l'infrastructure propre de l'administration. L'ensemble de la chaîne a d'ailleurs récemment été validé de bout en bout. Mais ce qui mérite vraiment l'attention d'une équipe publique, c'est un détail subtil : les permissions ne sont pas « collées sur un fichier ». Elles s'appliquent au moment même de la recherche. L'idée paraît abstraite, jusqu'au jour où on la voit fonctionner.
Un seul document mélange souvent des passages pouvant être rendus publics et d'autres, franchement sensibles. L'ancienne méthode forçait un choix tout ou rien au niveau du fichier — soit tout était ouvert, soit tout était verrouillé. Côté confort comme côté sécurité, personne n'y gagnait. Le socle actuel prend en charge des niveaux allant du public au restreint, et il pousse cette classification jusqu'au segment de contenu. Différents services, différents rôles, interrogeant la même base : chacun ne voit que la portion dont il est autorisé à disposer. Ce modèle « par personne, par segment » colle à la réalité administrative bien mieux qu'un verrou global : un même rapport montre un jeu de mesures à un responsable de division et un autre à un agent de bureau, exactement comme il se doit.
Pourquoi s'acharner sur ce point ? Le rapport Cost of a Data Breach 2025 d'IBM fixe un repère parlant : le coût moyen mondial d'une fuite de données a atteint 4,44 millions de dollars américains, pour un cycle de containment moyen de 241 jours. Les données publiques portent une sensibilité encore supérieure, et le prix d'une exposition dépasse de loin la dimension financière. Maintenir la base au sein de l'environnement propre de l'administration, avec des données qui ne quittent jamais l'intranet, réduit la surface d'exposition à la racine. Voilà ce que signifie ici le déploiement privé : ni un effet de mode ni un luxe, mais un socle minimal.
Sans migration, ni rupture
Fermer la porte ne suffit pourtant pas. Les équipes du secteur public traînent une crainte plus terre-à-terre : les données de leurs systèmes historiques sont-elles seulement déplaçables ?
À l'annonce de « construire une base de connaissances », la première réaction fuse souvent : « ça veut dire qu'on déménage toutes nos bases opérationnelles ? » En général, non. Une approche mûre se connecte directement aux bases de données déjà en place au sein de l'administration. Les données d'origine restent là où elles sont, dans leur propre domaine, tout en devenant recherchables et citables sous contrôle de conformité. Pour un service public, cela évite le grand déménagement traumatisant : les systèmes de dossiers scolaires, de sécurité sociale ou d'instruction continuent de tourner comme avant, pendant que la couche de connaissances vient puiser à côté. Les vieux systèmes n'ont pas à être abattus pour que surgisse une capacité nouvelle. C'est cette évolution douce qui, au fond, se fait réellement adopter dans les institutions.
Un autre risque passe souvent inaperçu : « une mise à jour efface ce qui était là ». Les documents administratifs portent de fortes exigences de conservation ; un dossier vieux de dix ans peut devoir être sorti n'importe quel jour. Le socle gère les mises à jour incrémentales : les nouveaux documents sont traités en delta plutôt que reconstruits à zéro à chaque passage, et chaque mise à jour laisse un instantané permettant de revenir en arrière si quelque chose déraille. La suppression par lot embarque une protection contre la suppression accidentelle en masse, si bien qu'un clic malheureux ne vide pas une bibliothèque entière. En clair, il enferme au cœur même du processus les deux phrases qui glacent tout administrateur — « on ne retrouve plus » et « c'est parti par erreur ».
La compression n'est pas un sujet à part
Un mot sur la compression, car il est tentant de la traiter comme une préoccupation séparée. Les documents publics sont lourds de PDF, de scans, de fichiers OFD, d'images et d'audio ou vidéo, souvent de plusieurs dizaines, voire centaines de mégaoctets chacun — trop volumineux pour être envoyés, trop coûteux à archiver, trop lents à ouvrir sans décalage. Dans des tests publiés, un document OFD de 443 pages a été compressé de bout en bout en 124 secondes, et la compression d'images a fait chuter le coût en tokens de leur alimentation à un grand modèle de langage d'environ 85,9 % (mesuré par rapport à la référence GPT-4o). Compression et RAG ne sont pas deux projets distincts : ce sont des maillons contigus d'une même chaîne. On réduit le fichier pour qu'il transite et se stocke bien, puis on en extrait la structure vers la base, et seulement alors la recherche et la génération peuvent tourner. Dans l'autre sens, le modèle s'étouffe sur la taille du document avant même d'avoir commencé.
Trois chemins, trois réalités
Comment les trois pistes pour bâtir une base de connaissances publique se distinguent-elles réellement ? Un tableau résume.
| Critère | Knowledge base SaaS cloud public | Simple stockage de fichiers local | RAG privé + compression |
|---|---|---|---|
| Résidence des données | Quitte le réseau de l'administration, hébergé par un tiers | Reste local | Reste dans l'environnement propre de l'administration, ne quitte jamais l'intranet |
| Granularité des permissions | Surtout au niveau fichier | Par dossier, maintenance manuelle | Classification par segments, appliquée au moment de la requête |
| Incrémental et restauration | Dépend du fournisseur | Quasiment aucune | Mises à jour incrémentales + restauration par instantané + protection anti-suppression |
| Intégration des systèmes existants | Export et migration requis | Systèmes en silos | Connexion directe aux bases existantes, aucun déplacement de données |
| Audit de conformité | Limité par la transparence du fournisseur | Difficile à tracer | Journaux d'audit et archivage du cycle de vie intégrés |
Ce tableau pose un cadre d'évaluation, rien de plus — aucun jugement sur un produit précis. Posées les dimensions, une équipe publique peut se retourner quelques questions : nos données peuvent-elles rester dans notre réseau ? Un contenu public et un passage sensible, dans un même document, peuvent-ils être autorisés séparément ? Les systèmes historiques peuvent-ils être reliés sans migration ? Pouvons-nous revenir en arrière si une mise à jour tourne mal ? Répondez, et la voie se choisit d'elle-même.
Revenons à l'aveugle du début. Une base de connaissances n'a jamais été « déplacer du papier dans un disque dur ». C'est faire voir à la bonne personne, au bon moment, la bonne portion — avec les données toujours entre ses mains. La singularité du secteur public tient en un nœud : il doit servir ouvertement tout en protégeant les classifications, se brancher sur l'existant sans tout reconstruire, conserver un dossier vieux de dix ans tout en faisant tourner les modèles d'aujourd'hui. Ce qui tresse ensemble ces exigences en apparence contradictoires est ce qui, réellement, trouve sa place.
Pour la vision complète, le socle d'ingénierie de données RAG et la présentation des produits UglyPear Data valent le détour ; d'autres notes d'ingénierie attendent dans le blog technique.
Essayez maintenant
Si vous planifiez une base de connaissances publique ou un hub documentaire privé, démarrez avec un seul jeu de fichiers pilote : choisissez un service et un type de document, puis faites tourner la petite boucle « compresser — structurer — rechercher — autoriser ». Les produits et solutions utiles se trouvent au socle d'ingénierie de données RAG et à la présentation des produits UglyPear Data ; les détails de déploiement et de choix sont dans le blog technique.
FAQ
Les données publiques doivent-elles obligatoirement être déployées en privé ?
Pour une base qui touche à des informations sensibles, le déploiement privé ou sur site constitue un choix par défaut prudent, les données demeurant à l'intérieur de l'intranet. Les informations purement publiques peuvent être traitées avec plus de souplesse. Le principe est de gradauer par sensibilité plutôt que d'appliquer une règle unique à tout.
Faut-il migrer l'intégralité des données des systèmes historiques ?
Non. L'approche peut se connecter directement aux bases existantes, de sorte que les données d'origine restent en place et dans leur domaine tout en devenant recherchables et citables — ce qui évite un déménagement de données douloureux.
Un document mêle contenu public et passages sensibles : comment le gouver ?
Une classification par segments est prise en charge, avec des permissions appliquées au moment de la requête ; chaque rôle ne voit que la portion dont il est autorisé à disposer. Aucun verrou tout ou rien au niveau du fichier n'est requis.
Les mises à jour n'écrase-t-elles pas et ne perd-on pas l'ancienne version ?
Les mises à jour incrémentales et la restauration par instantané sont prises en charge, permettant de revenir en arrière à tout moment ; la suppression par lot embarque une protection anti-suppression qui réduit le risque d'erreur humaine.
La compression nuit-elle à la qualité de recherche ou à la clarté de l'original ?
La compression cible la taille de stockage et de transmission ; les éléments de mise en page clés, comme les sceaux officiels et la structure tabulaire, sont conservés après compression. Le corps du texte est extrait de manière structurée pour la recherche, si bien que l'intégrité du contenu reste intacte.