Le problème : la réponse existe, mais personne ne la trouve
Une entreprise de construction et de géomètres vit de petits faits. Quand arrivent les armatures. Ce que disait le dernier relevé. Qui a chiffré quoi, et quand.
Ces faits existent. Ils sont simplement éparpillés :
- Notes vocales enregistrées en marchant sur le chantier
- Photos d'un plan annoté
- Tableurs envoyés une fois par mail et jamais rouverts
- PDF des fournisseurs et du cadastre
- Messages dans un groupe de discussion qui a défilé avant midi
Demandez « combien avons-nous dépensé en armatures en septembre ? » : la réponse est dans un tableur. Demandez « quand est la prochaine livraison ? » : elle est dans une note vocale de mardi. Personne n'a les deux en tête.
Alors on demande à un collègue. Le collègue va chercher. Deux personnes ne travaillent plus.
Pourquoi un moteur de recherche ne suffit pas
La recherche trouve des documents, pas des réponses. Tapez « armatures septembre » et vous obtenez cinq tableurs. Il faut encore les ouvrir et faire l'addition vous-même.
Et la plupart des outils IA documentaires ne savent pas compter. L'approche courante : découper en passages, retrouver ceux qui ressemblent à la question, les transmettre à un modèle de langage. Cela marche pour « que dit notre politique de sécurité ? ». Cela s'effondre sur « combien avons-nous dépensé ? ».
Une recherche par similarité sait trouver les lignes. Elle ne sait pas les additionner. Et elle ne peut pas dire quelle ligne elle a utilisée — donc rien n'est vérifiable.
Pour une entreprise qui signe des contrats sur la base de ces chiffres, une réponse invérifiable n'est pas une réponse.
Ce que nous avons construit
Un assistant interne, en croate, que les équipes utilisent comme un groupe de discussion.
Tout arrive au même endroit — messages écrits, notes vocales, tableurs, PDF, photos. Ensuite, chacun peut poser une question au fil et recevoir une réponse accompagnée d'un lien vers sa source.
Deux choses arrivent à tout ce qui entre.
D'abord, c'est conservé. Brut, immédiatement, avant toute tentative d'intelligence. Rien n'est jeté parce qu'un classifieur a eu un mauvais jour.
Ensuite, un filtre décide s'il s'agit d'une information métier. « La livraison arrive jeudi » en est une. « Qui veut un café ? » non. Ce qui passe est traité deux fois :
- Comme des faits dans une table — fournisseurs, dates, montants, matériaux. C'est ce qui rend le calcul possible.
- Comme du sens interrogeable — pour que « armatures » trouve aussi « acier à béton », et qu'une question formulée vaguement tombe juste.
Face à une question, l'assistant mobilise les deux. Une vraie requête en base pour tout ce qui est chiffré, une recherche par le sens pour tout ce qui est descriptif, puis une réponse construite à partir des deux.
Chaque réponse montre d'où elle vient
C'est ce qui comptait le plus pour le client.
Sous chaque réponse figurent des liens de source. Pas « d'après vos documents » — un lien vers la ligne exacte du tableur, la page du PDF ou le message d'où vient le chiffre. Un appui, et vous atterrissez sur cette ligne, surlignée.
Cela change le rapport à l'outil. Une réponse vérifiable en un geste est une réponse sur laquelle on agit.
Les dates sortent de la conversation
Le travail de chantier se planifie au passage. « On fera le relevé jeudi » se dit une fois, dans une note vocale, et ne s'écrit nulle part ailleurs.
L'assistant lit ces mentions et les inscrit dans un agenda, avec un lien vers la phrase dont elles proviennent.
Un détail a compté plus que prévu. Les gens se trompent couramment sur la moitié d'une date — ils diront « dimanche 18 » alors que le 18 est un vendredi. Plutôt que de laisser l'IA trancher en silence d'un ton assuré, l'incohérence est signalée à un humain. Une date fausse qui devient discrètement un engagement est pire qu'une absence de date.
Les points difficiles
Le croate est mal servi par les outils standards. La plupart des moteurs de recherche textuelle intègrent l'anglais et une douzaine d'autres langues. Pas le croate. Nous avons dû écrire le traitement linguistique nous-mêmes — y compris un bug où đ traverse l'étape standard de normalisation sans changer, si bien que toute recherche d'un nom comme Đuro échouait silencieusement. Il existe désormais un test dont l'unique raison d'être est d'empêcher qu'on « simplifie » cela.
Le filtre promeut, il ne supprime jamais. Les messages et fichiers d'origine sont toujours conservés. Le filtre décide seulement de ce qui part en traitement. Quand nous l'améliorons, nous pouvons donc le repasser sur tout l'historique — impossible si la première version avait jeté des choses.
C'est une application mobile, parce que le travail se fait dehors. Les équipes de terrain ne sont pas à un bureau. L'application est pensée pour une main, dans une camionnette ou sur le chantier : enregistrer une note vocale, photographier un plan, poser une question.
À qui ce modèle convient
Rien de spécifique au bâtiment. La même forme convient à toute entreprise où le savoir est réel mais dispersé, et où une mauvaise réponse a des conséquences :
- Services professionnels — historique des projets, périmètre des missions, qui a validé quoi
- Industrie — conditions fournisseurs, spécifications de pièces, historique des incidents
- Immobilier et exploitation — carnets d'entretien, coûts par site, historique des prestataires
- Toute entreprise qui vit dans un groupe de discussion — où la mémoire de l'entreprise est réellement dans le fil, et part avec les gens
Les deux éléments qui font que cela fonctionne méritent d'être répétés : combiner de vraies requêtes en base avec la recherche par le sens, et citer la source exacte. Sans le premier, l'outil ne sait pas compter. Sans le second, personne ne lui fait confiance.
