La première question d'un DSI face à un besoin de gestion documentaire multi-sites est souvent : « quel ERP on prend ? » C'est un réflexe compréhensible — mais rarement le bon diagnostic. Ce projet en est l'illustration directe. Un bureau d'études BTP, des filiales réparties aux quatre coins des DOM-TOM, des livrables techniques à émettre avec traçabilité contractuelle, et zéro besoin de comptabilité, de CRM ou de gestion des stocks. La réponse n'était pas un ERP. C'était quelque chose de plus petit, plus précis — et infiniment plus efficace.
Un BE technique avec des contraintes inhabituelles
Ce bureau d'études est une entité centralisée, basée à Paris, qui produit des livrables techniques pour une maison mère et des filiales réparties en Guadeloupe, Martinique, Réunion, Guyane, Mayotte et à l'international. Sa mission est exclusivement technique : plans 2D et 3D, métrés, estimatifs, notes de calcul, CCTP, DPGF.
Les contraintes opérationnelles sont significatives :
- Des décalages horaires pouvant atteindre UTC+11 avec certaines filiales
- Des connexions réseau parfois dégradées dans les territoires ultramarins
- Une traçabilité contractuelle obligatoire des émissions de plans — qui a reçu quoi, à quelle date, à quel indice
- Une séparation stricte entre la production technique (BE) et la gestion commerciale (chargés d'affaires)
Ce dernier point est fondamental. Ce BE ne vend pas, ne facture pas ses filiales, ne gère pas de stocks ni de ressources humaines. Il produit des livrables. C'est une entité purement technique — et le système d'information doit en tenir compte.
Tout système proposé à ce BE doit répondre à des flux métier simples mais précis : recevoir une demande, produire et versionner des documents, les émettre avec traçabilité, archiver. Rien de plus. Un système qui fait plus n'est pas meilleur — il est plus coûteux à déployer, plus difficile à adopter, générateur de complexité inutile.
Pourquoi pas d'ERP — une décision argumentée
Quand ce projet m'a été soumis, la question était posée en termes d'ERP. Odoo, Dynamics, une solution SaaS quelconque. J'ai pris le temps de cartographier les flux réels avant de répondre — et la réponse était claire.
Un ERP est conçu pour centraliser les flux d'une organisation complète : comptabilité, achats, ventes, RH, stocks, CRM, production. C'est sa force — et c'est exactement son problème pour un BE purement technique. Déployer un ERP ici, c'est utiliser 20 % de ses fonctionnalités en payant 100 % du coût.
| Critère | ERP sur ce BE | Stack ciblé aux besoins réels |
|---|---|---|
| Fonctions réellement utilisées | ~20 % du périmètre | ~100 % du périmètre |
| Coût mensuel (licences + infra) | 150 – 800 €/mois | 18 – 33 €/mois |
| Durée de déploiement | 3 – 6 mois | 3 – 4 semaines |
| Formation utilisateurs | Plusieurs jours par profil | 2 heures — interfaces web standard |
| Maintenance et montées de version | Complexe, risquée, souvent externalisée | Documentée, maîtrisée en interne |
| Dépendance éditeur / intégrateur | Forte — avenant à chaque évolution | Aucune — 100 % open source |
| Adéquation aux flux réels | Générique — adaptation coûteuse | Conçu pour les 4 flux identifiés |
La ligne la plus importante est la première. Un outil utilisé à 20 % de ses capacités n'amortit jamais son coût de déploiement. Il génère en plus une dette cognitive durable : menus inutiles, formation laborieuse, documentation interne qui explose, adoption qui stagne.
L'outil juste n'est pas le plus complet. C'est celui qui couvre exactement ce dont vous avez besoin — ni plus, ni moins.
— Principe directeur de ce projet
Les quatre flux qui définissent tout le système
Avant de choisir un outil, je cartographie toujours les flux métier réels. Pas les flux théoriques d'une PME générique — les flux concrets, quotidiens, de cette structure précise. Pour ce BE, quatre flux décrivent 95 % de l'activité :
Réception de la demande
- Une filiale soumet une demande structurée
- Le BE la reçoit, l'enregistre et ouvre un projet
Production des livrables
- Le BE produit les livrables techniques
- Versioning dans un espace structuré par indice
Émission et notification
- La filiale est notifiée automatiquement
- Téléchargement des documents à l'indice en cours
Clôture et archivage
- Le projet se clôture proprement
- Traçabilité complète conservée à l'archivage
Ces quatre flux ne nécessitent ni comptabilité, ni CRM, ni gestion des ressources humaines. Ils nécessitent : une GED robuste, du versioning documentaire, un système de notification fiable, et suffisamment d'automatisation pour éviter les tâches manuelles répétitives qui génèrent des erreurs.
Ce cadrage a déterminé le choix des outils — pas l'inverse. C'est la différence fondamentale entre une approche SI pilotée par le besoin réel et une approche pilotée par un catalogue éditeur.
L'architecture retenue : minimalisme applicatif et souveraineté
La solution repose sur un principe directeur : chaque outil a une responsabilité unique, les interfaces sont standards (web, mobile), et l'ensemble est hébergé sur une infrastructure souveraine en France. Zéro licence propriétaire.
Architecture globale — Vue fonctionnelle
L'ensemble tourne sur un VPS unique hébergé en France. Nextcloud gère tout ce qui touche aux fichiers et à la collaboration — c'est le référentiel central. n8n orchestre les flux automatisés : création de projet, émission de plans, archivage — sans intervention manuelle.
L'automatisation : ce qui se passe sans intervention
L'un des points de friction les plus fréquents dans les BE que j'observe : les tâches manuelles répétitives à faible valeur ajoutée qui finissent par ne plus être faites — ou faites avec des erreurs. Créer les dossiers projet à la main, envoyer les mails d'émission un par un, penser à archiver en fin de projet.
Sur ce projet, cinq workflows couvrent ces tâches. Quand une filiale soumet une demande, le projet est créé automatiquement — dossier structuré, carte kanban ouverte, templates en place, notification aux bons interlocuteurs. Quand un livrable est déposé pour émission, la filiale concernée reçoit une notification avec lien de téléchargement sans que le BE n'ait à rédiger un seul mail. Les rappels de deadline partent à J-7 sans agenda manuel. En fin de projet, l'archivage et la révocation des accès filiale sont déclenchés par un simple changement de statut.
Zéro mail d'émission rédigé manuellement. Zéro dossier projet oublié sans arborescence. Zéro relance de deadline non envoyée. Ce sont des gains opérationnels directs — pas des fonctionnalités sur une plaquette commerciale.
Un point important sur la maintenabilité : n8n est une interface visuelle. Les workflows sont des schémas, pas du code. Un collaborateur avec des bases informatiques peut les modifier sans faire appel à un prestataire externe. C'est le contraire d'un module ERP custom, dont chaque évolution nécessite un intégrateur certifié et un avenant.
Gestion documentaire : versioning, droits et traçabilité
La traçabilité des émissions est une contrainte contractuelle sur ce projet. Il faut pouvoir répondre à la question : « qui a reçu le plan PROJ-001 à l'indice B, et quand ? » à tout moment, des mois après la clôture.
Nextcloud répond à cette exigence de trois façons : le versioning natif conserve l'historique de chaque fichier, le journal d'audit enregistre chaque accès et chaque téléchargement avec horodatage, et les émissions sont organisées par dossier horodaté avec liens de partage à durée limitée — dont n8n conserve la trace à chaque déclenchement.
Les droits d'accès sont organisés en trois niveaux : l'équipe BE à Paris avec accès complet sur tous les projets, chaque filiale avec accès en lecture et dépôt uniquement sur ses propres projets — sans visibilité sur les projets des autres filiales — et les chargés d'affaires avec accès en lecture sur les livrables finaux émis.
La convention de nommage des fichiers doit être validée et figée avant le premier projet. Un changement rétroactif sur une arborescence déjà peuplée génère un chaos documentaire difficile à résorber. Un atelier de 2 heures avec l'équipe BE avant démarrage — c'est non négociable.
Déploiement : 3 à 4 semaines, 5 phases
Le déploiement est organisé en cinq phases séquentielles. Chaque phase produit des livrables validés avant de passer à la suivante — pas de mise en production partielle.
Infrastructure
VPS, containers Docker, reverse proxy Nginx, DNS et certificats SSL Let's Encrypt. Environnements de staging et production isolés.
Configuration Nextcloud
Groupes et droits utilisateurs, modules activés (Deck, Forms, Talk), arborescence template, fichiers modèles déposés.
Validation convention de nommage
Atelier de 2 heures avec l'équipe BE. Validation de la structure de dossiers et des règles de nommage des livrables. Gel des décisions avant démarrage.
Automatisation n8n
Déploiement des 5 workflows, configuration du relay SMTP (SPF/DKIM), tests de bout-en-bout sur chaque flux.
Recette, formation, documentation
Projet pilote complet avec l'équipe BE. Formation de 2h. Documentation utilisateur pour les filiales. Mise en production.
Charge totale : 11 jours-homme. Infrastructure souveraine opérationnelle en production à l'issue de la semaine 4.
Les résultats
Réception structurée des demandes filiales · Versioning et traçabilité complète des livrables · Émission de plans avec notification automatique · Communication intégrée BE ↔ filiales · Gestion de projet légère (kanban) sans surcharge ERP · Automatisation des flux répétitifs · Données hébergées en France.
Les objections que j'entends souvent
« On aura peut-être besoin d'un ERP plus tard »
Peut-être. Mais un ERP s'adopte quand les flux qui le justifient existent — pas en anticipation. Partir d'un stack léger et ajouter des briques si le besoin émerge est infiniment plus sain que déployer un ERP complet en espérant qu'il serve un jour. Et si ce besoin arrive, la migration depuis une GED propre vers un ERP est beaucoup plus simple qu'un désengagement d'un système mal adopté depuis deux ans.
« Nextcloud, c'est juste du stockage de fichiers »
C'était vrai il y a quelques années. Aujourd'hui Nextcloud intègre un kanban (Deck), une messagerie avec visioconférence (Talk), des formulaires de collecte, un calendrier partagé et un journal d'audit complet. Pour un BE technique, c'est exactement ce qu'il faut — et c'est son avantage : pas de superflu à maintenir.
« Un VPS auto-hébergé, c'est risqué »
Un VPS mal configuré, oui. Ce déploiement intègre SSL automatique, isolation des services par containers, relay SMTP avec SPF/DKIM, accès administration restreint, et backup quotidien avec procédure de restauration testée. Ce n'est pas moins sécurisé qu'un SaaS dont vous ne contrôlez pas l'infrastructure — et les données restent en France, sous votre contrôle.