« Stack open source pour piloter un chantier » sonne ambitieux. Pas tant que ça : les fonctions dont une équipe projet de construction a besoin existent aujourd’hui en open source, matures, déployables sur une infrastructure locale. Il manque parfois la couche d’intégration, mais ça, c’est notre métier.
Ce qui suit n’est pas exhaustif. C’est la boîte à outils que nous installons concrètement, par couche, avec les vraies alternatives. Rien d’idéal sur le papier : du déjà en production, sur des projets que vous connaissez peut-être.
Par couche, ce qu’on met
| Couche | Outil open source | Remplace |
|---|---|---|
| Planning & OPC | OpenProject · ProjectLibre · GanttProject | MS Project · Primavera P6 |
| GED chantier | Nextcloud · Seafile · Paperless-ngx | SharePoint · Box · Dropbox Business |
| Messagerie équipe | Mattermost · Element (Matrix) | Slack · Teams |
| Réunions / visio | Jitsi Meet · BigBlueButton | Zoom · Google Meet · Webex |
| Transcription | Meetily · Whisper | Otter · Fireflies · Read.ai |
| Notes & wiki | Obsidian (+ plugins) · Logseq · Outline | Notion · Confluence |
| LLM local | Ollama · llama.cpp · LM Studio | OpenAI · Anthropic · Mistral API |
| RAG (recherche augmentée) | Verba · Quivr | OpenAI Assistants · Glean · Mendable |
| BIM / CAO | FreeCAD · BlenderBIM · BIMServer | Autodesk · Bentley · Trimble |
| Base de données | PostgreSQL · SQLite | Oracle · SQL Server (côté serveur d’app) |
| CRM (commercial) | EspoCRM · Twenty | Salesforce · HubSpot |
Sur un grand projet, on n’utilise pas tout : on prend ce qui sert. Mais l’éventail est là, et chaque ligne représente une dépendance SaaS en moins.
Où ça tourne
Question récurrente : « Mais où on l’installe, tout ça ? ». La réponse n’est pas un seul serveur ni un cloud unique. C’est une architecture locale, sur-mesure, calibrée selon le projet.
Cas 1 · Petit projet / opération courte (10 personnes, < 12 mois)
Un seul ordinateur compact à la base vie chantier suffit. Il fait tourner un LLM local, un moteur de recherche augmentée et PostgreSQL. Côté coûts : un ordinateur de bureau acheté une fois, aucune licence, une demi-journée de formation.
Cas 2 · Projet moyen (50 personnes, 24 mois)
Un ordinateur compact sur le chantier plus un petit serveur Linux (Hetzner, OVH ou self-hosted DC) pour Nextcloud, Mattermost, OpenProject. Le serveur central est en Europe, en France si critique. Bande passante : pas un sujet sur un chantier européen.
Cas 3 · Grand projet / consortium (200+ personnes)
Architecture distribuée : un serveur central par MOE / GC, un ordinateur compact sur chaque chantier majeur, fédération possible entre instances Mattermost / Nextcloud. C’est là que ça demande du cadrage, mais la techno est mature, on n’invente rien.
L’open source n’est pas une utopie pour développeurs. C’est juste l’infrastructure qu’on n’aurait jamais dû arrêter d’utiliser.
Le coût comparé
Comparer le coût d’une stack open source à une stack SaaS est délicat : le SaaS facture un coût visible (par utilisateur, par mois), l’open source demande du temps d’installation et de maintenance. Mais sur 24 mois, sur un projet de 50 personnes, l’écart est structurel :
- Boîte à outils SaaS classique (MS Project + SharePoint + Teams + Otter + ChatGPT + Salesforce) : un abonnement par utilisateur et par mois, pour chaque brique, qui court aussi longtemps que le projet.
- Boîte à outils open source auto-hébergée : une infrastructure facturée globalement et non par utilisateur, le temps d’installation initial (3 à 5 jours pour la première mise en place) et une maintenance régulière, de l’ordre d’un jour par mois.
Sur deux ans et cinquante intervenants, le premier coût croît avec l’effectif, le second non : c’est là que l’écart se creuse. Mais ce n’est pas le seul intérêt. L’open source vous donne aussi :
- La maîtrise des données. Elles ne quittent pas votre infrastructure.
- L’absence de lock-in. Vous pouvez migrer, exporter, modifier.
- L’auditabilité. Le code est lisible, vérifiable, certifiable.
- La continuité. Pas de risque qu’un éditeur change ses prix ou arrête le produit.
Les vraies limites
Il faut être honnête : tout n’est pas parfait dans l’open source.
L’expérience utilisateur n’est pas toujours au niveau d’un SaaS commercial. Mattermost est plus brut que Slack. OpenProject demande un peu d’apprentissage là où MS Project est familier. Nextcloud est moins fluide que SharePoint sur certains workflows.
Le support est communautaire : c’est puissant mais asynchrone. Pour des incidents critiques, soit on prend un contrat de support payant chez l’éditeur open source (Nextcloud Enterprise, OpenProject Cloud Edition…), soit on mutualise avec un prestataire qui connaît la stack.
L’intégration entre outils n’est pas plug-and-play. C’est là que beaucoup de DSI capitulent et reprennent un SaaS tout-en-un. Mais c’est aussi là qu’on apporte de la valeur : relier les briques entre elles, c’est notre métier.
Comment commencer, sans tout faire d’un coup
Le piège classique est de vouloir tout migrer en même temps. Mauvaise idée. La séquence qu’on conseille :
- Mois 1 · Transcription. Remplacer Otter par Meetily ou Whisper local. Friction faible, gain immédiat, valeur démontrable.
- Mois 2-3 · Messagerie. Déployer Mattermost en parallèle de Teams / Slack. Migrer un projet pilote dessus.
- Mois 4-6 · GED chantier. Nextcloud en doublon avec SharePoint sur un projet test. Évaluer.
- Mois 7-12 · Planning. OpenProject sur un projet pilote. Garder MS Project sur les autres pendant la transition.
- Année 2 · IA locale. Une fois l’infrastructure stabilisée, déployer le LLM local, puis la recherche augmentée.
À chaque étape, on garde une porte de sortie : si une brique ne convient pas à l’usage réel, on revient au SaaS sur ce périmètre. Pas de dogme.
Le mot de la fin
Ce qui rend l’open source viable en 2026 (et pas en 2018), c’est trois choses : les modèles IA open weights ont rattrapé le retard, le matériel local est devenu très puissant pour pas cher (un ordinateur compact suffit), et la communauté open a produit des outils mûrs sur tous les périmètres.
Ce qui reste, c’est l’orchestration. Qui parle à qui, comment, dans quel ordre. C’est ce qu’on installe : pas un produit, une architecture choisie selon votre contexte.
Si vous voulez voir à quoi cela ressemble en pratique sur un chantier, Cabestian OS en est la démonstration. Et la page communauté liste les briques qu’on admire et qu’on déploie le plus souvent. Pour en discuter sur un projet précis, la prise de rendez-vous est là pour ça.