DocuMind AI — concevoir une application documentaire SaaS

J’ai commencé DocuMind AI pour approfondir la conception d’une application SaaS complète, à partir de mon intérêt pour la gestion documentaire. Je voulais relier une interface web, une API et une base de données, tout en travaillant sur la sécurité, l’intégration maîtrisée de l’IA et l’exploitation sur mon infrastructure personnelle. Le projet est encore en développement : la bêta publique est en préparation et n’est pas ouverte.

Je souhaite permettre à chaque personne de centraliser ses documents dans un espace personnel, de les organiser, de consulter leur contenu et de l’analyser. L’objectif est aussi de séparer strictement les données entre utilisateurs et de préparer des analyses avancées sans perdre le contrôle de leur activation et de leurs coûts.

Je développe l’interface et les services applicatifs, et je prépare les mécanismes de sécurité, les tests, les procédures de déploiement et de sauvegarde.

J’ai séparé l’application en plusieurs responsabilités. Le navigateur affiche une interface React et TypeScript ; il passe par un BFF (Backend for Frontend), un service Node qui adapte les échanges à l’interface et gère la session. Le BFF transmet les requêtes autorisées à l’API FastAPI en Python, qui applique les règles métier et d’accès. PostgreSQL conserve les données applicatives, tandis que les fichiers originaux sont stockés séparément. Le navigateur n’accède pas directement à la base.

J’utilise Docker et Docker Compose pour assembler les services, et Traefik pour le routage HTTPS sur mon VPS Debian. Cette séparation m’aide à raisonner sur les frontières de confiance : l’identité du service BFF ne remplace jamais la session personnelle nécessaire pour accéder aux documents.

L’analyse classique ne dépend pas d’un fournisseur IA. J’ai également prévu des composants d’analyse avancée et des limites de consommation, mais leur présence dans le code ne signifie pas qu’ils sont disponibles pour la bêta. Les fonctions IA restent désactivées pour son lancement initial.

J’ai travaillé sur l’authentification, les sessions sécurisées, la protection des routes et la vérification des permissions côté serveur. Un document est recherché selon son propriétaire : connaître son identifiant ne suffit pas pour y accéder. Lors du téléchargement individuel, l’application vérifie notamment la taille et l’empreinte du fichier avant de le transmettre ; une anomalie entraîne un refus plutôt qu’un téléchargement présenté comme valide.

Pour préparer l’ouverture progressive, j’ai ajouté une vérification d’email et un plafond de cinq admissions publiques cumulatives. Une place consommée n’est pas rendue par la suppression du compte. Un verrou SQL distinct permet de fermer les admissions indépendamment du compteur ; en cas d’état incohérent, l’admission est refusée. J’ai testé localement des inscriptions concurrentes avec des transactions PostgreSQL indépendantes.

La désactivation de l’IA est contrôlée jusque dans les points d’appel aux fournisseurs ; les analyses classiques restent utilisables. Les secrets sont conservés dans la configuration serveur, pas dans le code envoyé au navigateur. Les contrôles et les tests locaux ne remplacent toutefois pas la vérification de la configuration réellement déployée.

Je prépare le déploiement conteneurisé sur mon VPS avec des images Docker identifiées par leur version et leur empreinte. Les workflows GitHub Actions exécutent les contrôles et produisent les éléments nécessaires à une livraison contrôlée ; un envoi de code ne déclenche pas automatiquement un déploiement. Avant une nouvelle release, je prévois la vérification des images, des attestations et de leur provenance, puis une décision de déploiement distincte.

J’ai également préparé des sauvegardes locales et leur transfert chiffré avec Restic vers Backblaze B2, des vérifications d’intégrité, des contrôles de santé et de supervision, ainsi que des procédures de restauration et de reprise. Une restauration isolée d’un ancien snapshot a été validée par l’administratrice. Les contrôles de la version actuelle sur le VPS, la restauration distante et l’activation des tâches prévues restent à confirmer.

La politique de conservation des sauvegardes est simulée : la suppression automatique locale ou distante n’est pas activée. En cas d’incertitude ou d’incohérence, les outils prévus refusent les opérations dangereuses plutôt que de supprimer des copies.

Après connexion, une personne peut importer un PDF ou un fichier texte, consulter le texte extrait et lancer une analyse classique, par exemple pour examiner les mots fréquents et la structure du contenu. Elle peut ensuite retrouver ou supprimer son document dans son espace personnel.

Dans le code actuel, elle peut aussi télécharger individuellement son fichier original après contrôle de propriété et d’intégrité. Ce parcours a été testé localement ; sa recette HTTPS sur la version de production reste à faire. L’export global en ZIP n’est pas implémenté.

Les rapports indiquent une version antérieure en production avec inscriptions et IA fermées, sans inspection distante récente. Les améliorations récentes, notamment le téléchargement et les garde-fous de la bêta, sont implémentées et testées localement mais ne sont pas attestées comme déployées. L’ouverture publique reste conditionnée à une release vérifiée, aux recettes d’exploitation et à la validation des textes juridiques.

Préserver l’isolation et l’intégrité

Pour éviter qu’un compte accède aux documents d’un autre, j’ai fait porter les contrôles sur le propriétaire au niveau de l’API, puis testé les accès intercomptes. J’ai aussi traité un cas plus subtil : une erreur peut survenir après la validation d’une transaction en base. Supprimer immédiatement le fichier dans ce cas risquait de laisser un document enregistré sans original. La solution testée localement vérifie l’état par une connexion indépendante et conserve le fichier si cet état reste incertain.

Éviter une ouverture ou une suppression accidentelle

Une simple option de configuration ne suffisait pas à sécuriser une ouverture publique. J’ai combiné un verrou SQL, un compteur transactionnel et des contrôles de configuration, puis testé les accès simultanés et les états incohérents. Pour les sauvegardes, j’ai choisi une simulation de rétention et un refus des suppressions effectives tant que leur sûreté n’est pas démontrée.

Livrer et vérifier sans confondre préparation et production

J’ai organisé les tests automatisés du backend, du BFF et de l’interface, ainsi que des contrôles de build et des procédures de release. Une image locale ou une simulation ne prouve pas qu’une version est prête sur le VPS : les digests, attestations, sauvegardes, parcours HTTPS et possibilités de reprise doivent encore être vérifiés sur la stack cible avant une livraison autorisée.