Pourquoi la construction a besoin d’IA locale, pas de SaaS US.

Vos audios partent sur leurs serveurs, vos dossiers sont indexés à l’autre bout du monde. L’IA peut tenir sur la machine du chantier. Voici pourquoi, et comment commencer.

La construction française a accumulé une dette de dépendance. Otter pour les comptes-rendus de réunion. Notion pour la documentation. Salesforce pour les opportunités. Et maintenant, des copilotes IA, facturés au siège, au modèle, au jeton.

Chaque outil pris isolément résout un problème réel. Pris ensemble, ils déplacent vos données, votre gouvernance et votre marge à l’autre bout du monde.

Trois constats qui devraient déranger

Un. Les comptes rendus d’une réunion de coordination où l’on discute d’une réclamation finissent dans un cloud étranger. La clause RGPD est satisfaite dans la lettre, pas dans l’esprit.

Deux. Les modèles d’IA générale (GPT, Claude) ont vu nos plans, nos OS, nos contradictoires. On le sait. Ce qu’on ignore : combien de temps ils les gardent, à quoi ils servent, à qui ils peuvent être ressortis.

Trois. Les éditeurs SaaS qui hébergent vos données peuvent changer leurs prix, leurs CGU, leur politique de sortie. Vous découvrez la dépendance le jour où la facture double, ou le jour où votre concurrent rachète votre fournisseur.

Sur un chantier, on n’a pas de seconde chance. L’outil doit tenir, et s’il tient mal, il faut pouvoir le réparer soi-même.

L’alternative existe, et elle tient

En 2023, l’idée de faire tourner un grand modèle de langage sur un ordinateur de bureau relevait de la science-fiction. En 2025, c’est devenu un dimanche après-midi de configuration. llama.cpp, Ollama, vLLM permettent aujourd’hui d’exécuter en local les modèles open-weights (Llama, Mistral, Qwen, Gemma) à des qualités proches de ce que proposent les API cloud.

Du côté du RAG (recherche augmentée : donner à l’IA accès à vos dossiers), des projets comme Verba ou Quivr sont déployables sur un serveur de votre infrastructure. Vos documents sont indexés chez vous. Les recherches ne partent pas.

Pour les meetings, Meetily transcrit et résume en local, sans qu’aucun fichier audio ne quitte la machine. Le contraire exact d’Otter.

Pourquoi la construction en particulier

Le secteur de la construction concentre trois caractéristiques qui rendent l’IA locale presque évidente :

  • Confidentialité contractuelle élevée. Marchés, dérapages, réclamations, mémoires techniques, autant de matière sensible qui ne devrait pas transiter par un cloud tiers.
  • Connectivité variable. La machine d’un chantier en zone blanche doit fonctionner. Une IA dépendante d’une API cloud ne tient pas la promesse.
  • Cycle long. Un projet de construction dure 18, 36, 60 mois. Le risque d’évolution d’un éditeur SaaS sur cette durée est colossal.

Comment commencer (sans tout refaire)

Trois portes d’entrée raisonnables, par ordre d’impact croissant :

  1. Transcription locale. Remplacer Otter/Fireflies par Meetily ou un Whisper local. Bénéfice immédiat, friction faible.
  2. Recherche augmentée locale. Indexer vos dossiers et vos correspondances dans un moteur de recherche hébergé chez vous.
  3. Agent métier dédié. Construire un agent qui veille en continu sur les flux du chantier (mails, plannings, OS) et alerte. C’est ce que nous déployons avec Cabestian OS.

Le pari Cabestian

Notre conviction est simple : l’IA dans la construction sera locale, ou ne sera pas crédible. Les éditeurs US ont peut-être les meilleurs modèles aujourd’hui, mais ils ne tiendront pas la promesse de souveraineté des projets sensibles. Les outils open source, eux, ont comblé l’essentiel de l’écart, et il se referme à chaque version.

Cabestian aide à monter cette transition. Pas avec un produit unique imposé, mais avec une boîte à outils choisie selon votre contexte. Avec un principe non négociable : vous restez propriétaire de vos données, de votre code, et de votre stratégie de sortie.

Si ces trois mots (propriétaire, lisible, hébergeable) résonnent dans votre cahier des charges, on peut en parler.