DocsGPT : plateforme RAG et agents auto-hébergée, ce que le dépôt montre vraiment

Le problème visé : chercher dans ses propres documents sans sortir de son infrastructure

La promesse du dépôt tient en une phrase de son README : une plateforme d'IA open source pour construire des agents et des assistants, avec un contrôle complet de la confidentialité et la possibilité de déployer n'importe où. Le public visé n'est donc pas le développeur qui veut brancher un modèle sur trois PDF, mais l'équipe qui doit rendre interrogeable un corpus interne hétérogène et qui refuse de l'envoyer à un service tiers. Le README liste les formats pris en charge : PDF, DOCX, CSV, XLSX, EPUB, MD, RST, HTML, MDX, JSON, PPTX, des images, ainsi que des fichiers audio MP3, WAV, M4A, OGG et WebM. Cette largeur de formats est le vrai argument du projet. La plupart des briques RAG publiées séparément supposent un pipeline de texte déjà propre ; ici, l'ingestion est traitée comme un problème de premier plan, avec des sources qui vont au-delà des fichiers : URLs, sitemaps, Reddit, GitHub et robots d'exploration web. S'y ajoutent des flux vocaux, avec enregistrement de la voix dans le chat et transcription côté backend, ce qui permet d'indexer des comptes rendus de réunion comme n'importe quel autre document. C'est un positionnement d'outil interne d'entreprise, pas de bibliothèque de recherche.

Ce que la structure du dépôt révèle sur l'architecture

Le README décrit une organisation en trois blocs. Le premier, `docsgpt`, est une application Flask en Python, distribuée comme paquet du même nom. Le deuxième regroupe les extensions et widgets, avec Chatwoot et un widget React cités en exemple. Le troisième est le frontend, construit avec Vite et React. Le README renvoie aussi à un schéma d'architecture, mais l'image n'est pas exploitable dans le texte fourni : je ne peux donc pas décrire les flux internes entre ces blocs, et je préfère le dire plutôt que de reconstituer un diagramme plausible. Ce que l'on peut affirmer, c'est que la séparation backend Flask / frontend Vite implique deux runtimes distincts à opérer, et que la présence d'un paquet Python nommé `docsgpt` suggère que le backend est importable indépendamment du reste, même si le README ne documente pas cet usage. Le point d'entrée annoncé pour l'utilisateur est l'interface web sur le port 5173, ce qui confirme que le chemin normal passe par le frontend et non par une API appelée directement. Les fonctionnalités décrites dans le roadmap récent éclairent la maturité du socle : migration de Postgres pour les données utilisateur, observabilité OpenTelemetry, planification d'agents adossée à RedBeat, authentification OIDC/SSO avec provisionnement SCIM et groupes, tableau de bord administrateur et contrôle d'accès par rôles. Autrement dit, le dépôt a dépassé le stade de la démonstration de recherche sémantique et porte désormais des préoccupations d'exploitation : identité, rôles, traçabilité, ordonnancement.

Mise en route : les commandes du README, sans raccourci

Le README suppose Docker installé. La séquence est explicite : `git clone https://github.com/arc53/DocsGPT.git`, puis `cd DocsGPT`. Sous macOS et Linux, on lance `./setup.sh` ; sous Windows, `PowerShell -ExecutionPolicy Bypass -File .\setup.ps1`. Le script n'est pas un simple installeur : il propose cinq options, à savoir utiliser l'API publique, exécuter le tout localement, se connecter à un moteur d'inférence local, passer par un fournisseur d'API cloud, ou construire l'image Docker localement. Il configure automatiquement le fichier `.env` et gère les téléchargements et installations nécessaires selon l'option choisie. L'interface est ensuite accessible sur `http://localhost:5173/`. Pour arrêter l'ensemble : `docker compose -f deployment/docker-compose.yaml down`. Ce chemin de fichier est le seul indice concret sur le nombre de services impliqués, et il vaut la peine de l'ouvrir avant de lancer le script si vous devez estimer les ressources. Le README précise enfin qu'un guide d'environnement de développement existe séparément, à l'adresse indiquée dans la documentation, pour ceux qui veulent modifier le code plutôt que le déployer. Rien dans le matériel fourni ne décrit le contenu exact du `.env` généré ni les clés attendues par fournisseur : c'est une zone à inspecter vous-même.

Agent Builder, recherche approfondie et outils : ce que le README affirme, et ce qu'il ne dit pas

Le projet met en avant un Agent Builder avec nœuds conditionnels, un mode recherche, et une connexion d'outils permettant au modèle de déclencher des actions vers des API et services externes. Le roadmap confirme la livraison de l'Agent Workflow Builder avec nœuds conditionnels en février 2026, du mode recherche en mars 2026, et de l'import/export d'agents en juin 2026. Ces éléments sont datés dans le dépôt, ce qui est un bon signe de suivi, mais le README ne documente pas la syntaxe d'un workflow, le format d'export d'un agent, ni la manière dont les nœuds conditionnels évaluent une branche. Impossible, à partir de ce matériel, de dire si un agent se décrit en JSON, en YAML ou via l'interface uniquement. C'est une lacune documentaire réelle pour quiconque veut versionner ses agents dans Git. Le même flou entoure les intégrations : le README cite des widgets HTML/React, des outils de recherche, des bots Discord et Telegram, et un jeu de clés d'API liées aux paramètres, documents et modèles de l'utilisateur. La phrase du README sur des réponses fiables et sans hallucination, avec citations consultables dans l'interface, est un objectif de conception, pas une garantie mesurée : aucun chiffre d'évaluation n'accompagne cette affirmation, et il faut la traiter comme telle.

Limites et cas où DocsGPT est le mauvais outil

La première contrainte est le mode de déploiement. Le chemin officiel passe par Docker Compose et un script interactif, avec un frontend distinct sur le port 5173. Si votre besoin est d'appeler une fonction d'indexation depuis un service Python existant, cette plateforme ajoute des composants dont vous n'avez pas besoin, et le paquet `docsgpt` n'est pas présenté dans le README comme une bibliothèque à intégrer. La deuxième contrainte est la dépendance à un moteur d'inférence ou à un fournisseur : le README liste OpenAI, Google, Anthropic, Ollama et llama_cpp, et le roadmap mentionne un Bring Your Own Model livré en avril 2026. Le choix existe, mais chaque option a son propre coût opérationnel, et rien dans le matériel ne permet de comparer la qualité de réponse entre fournisseurs. La troisième est la maturité inégale des connecteurs : SharePoint et Confluence sont marqués comme livrés au roadmap sur mars à avril 2026, ce qui signifie que toute version antérieure à cette période ne les contient pas, et que la profondeur de synchronisation de ces connecteurs n'est pas décrite. Enfin, l'échelle : le README évoque un support Kubernetes et une conception pour la fiabilité en entreprise, mais sans chiffres de charge, de latence ou de volumétrie d'index. Pour un corpus de quelques milliers de pages, c'est probablement suffisant ; pour des dizaines de millions de chunks, vous avancez sans repère publié.

Face à une chaîne RAG assemblée à la main

L'alternative la plus directe n'est pas un produit concurrent mais une pile composée : un cadre d'orchestration comme LangChain ou LlamaIndex pour le découpage et la récupération, une base vectorielle comme Qdrant ou pgvector, et une interface écrite par votre équipe. La différence d'approche est nette. DocsGPT livre une application complète avec base de données utilisateur migrée vers Postgres, rôles, équipes, SSO OIDC, journalisation par agent et planification de tâches : vous adoptez des décisions déjà prises sur l'authentification, le stockage et l'ordonnancement. Une pile assemblée vous laisse chaque choix, au prix du temps passé sur l'ingestion des formats Office, audio et images, que DocsGPT traite déjà. Le second point de comparaison est le service cloud du même projet, accessible sur app.docsgpt.cloud. Si la contrainte de résidence des données n'existe pas dans votre organisation, le service hébergé supprime la charge d'exploitation ; l'auto-hébergement n'a d'intérêt que si vous devez garder documents et clés de modèle chez vous. C'est le seul arbitrage qui compte ici, et le README le formule lui-même en termes de contrôle de la confidentialité.

Coût de maintenance, licence et points à vérifier avant adoption

Le rythme de publication est soutenu : 0.17.3 en juin 2026, 0.18.0 le 26 juin 2026, 0.19.0 le 13 août 2026, avec un dernier push au 9 septembre 2026. Un cycle de versions mineures tous les un à deux mois implique de prévoir une procédure de mise à jour, d'autant que le roadmap annonce des migrations structurelles comme le passage à Postgres pour les données utilisateur. Ce type de changement touche le schéma de votre base et mérite une sauvegarde avant chaque montée de version. La licence est MIT, ce qui autorise l'usage commercial, la modification et la redistribution, à condition de conserver l'avis de copyright et le texte de licence. Le dépôt contient un fichier LICENSE à la racine. Je ne donne pas d'avis juridique : si vous redistribuez DocsGPT dans un produit, faites relire les mentions de copyright et vérifiez séparément les licences des modèles et des dépendances que vous associez, car MIT ne couvre que le code de ce dépôt. Un dernier point pratique : le projet propose un programme Lighthouse et un support payant pour les déploiements en production, ce qui suggère que l'équipe considère la mise en production comme nécessitant de l'accompagnement. Traitez cela comme un signal sur la complexité du déploiement, pas comme une obligation d'achat.

Conclusion éditoriale

DocsGPT convient aux équipes qui veulent garder leurs documents et leurs clés de modèle sur leur propre infrastructure, et qui acceptent de piloter un déploiement Docker multi-services plutôt qu'un simple paquet Python. Il ne convient pas à qui cherche une bibliothèque RAG minimale à importer dans une application existante : le dépôt livre une plateforme complète avec frontend Vite et React, pas une brique isolée. Avant de vous engager, vérifiez trois points dans votre propre copie du dépôt : la lecture de setup.sh et de deployment/docker-compose.yaml pour compter les services réellement démarrés, le contenu du fichier .env généré pour savoir quelles clés de fournisseur sont attendues, et la présence d'un connecteur SharePoint ou Confluence dans la version que vous déployez, puisque ces connecteurs figurent au roadmap avec une échéance de mars à avril 2026.

Sources officielles

1. arc53/DocsGPT on GitHub
2. License: MIT
3. Project website
4. README
5. Releases