Pourquoi nous avons créé Biilby : vivre dans le chaos

Un chantier tourne sur des milliers de petits problèmes.

Parfois, c'est une grosse crise, un incident qui finit en réunion de débriefing. Mais le plus souvent, ce n'est pas ce qui use vraiment un projet. C'est un flux continu de petits accrocs : une livraison qui arrive avec six panneaux en moins, un sous-traitant absent sur le lot 4, un client qui change d'avis sur une couleur de carrelage pendant une conversation de cinq minutes sur site, un détail qui ne colle pas tout à fait au plan, une question qui attendait une réponse depuis hier. Aucun de ces petits problèmes ne met le projet en péril à lui seul. Mais mis bout à bout, ils sont le projet.

C'est le point de départ de Biilby, et autant le dire clairement : nous ne pensons pas que ce chaos soit un problème à résoudre. Nous pensons que c'est la condition permanente du chantier — et que la plupart des outils construits pour ce métier ont échoué parce qu'ils refusent de l'accepter.

Le chantier ne sera jamais organisé

Tous les outils de gestion de projet jamais vendus au secteur de la construction ont fait la même promesse implicite : organisez bien votre chantier, saisissez bien vos données, suivez bien le process — et vous aurez de la visibilité et du contrôle.

C'est une promesse qui a l'air raisonnable. C'est aussi une promesse presque jamais tenue, parce qu'elle demande quelque chose que le chantier ne peut pas donner : une discipline soutenue, de la part de dizaines de personnes, tous les jours, sous pression, sur le terrain, les mains dans le mortier, avec cinq autres choses à faire en même temps.

Alors les outils restent à moitié remplis. Le planning Gantt arrête d'être mis à jour dès la troisième semaine. Le reporting hebdomadaire se résume à une entrée écrite de mémoire, plusieurs jours après les faits. Pendant ce temps, le vrai projet — celui qui détermine si le chantier finira dans les temps et dans le budget — se déroule ailleurs : dans une dizaine de fils WhatsApp, dans des conversations de couloir, dans des photos envoyées sans contexte, dans des décisions prises à l'oral et jamais consignées.

Cet écart — entre le projet propre attendu par les outils et le projet réel, désordonné — est là où la valeur disparaît. Pas par négligence, mais parce que ces outils demandaient au chantier de devenir quelque chose qu'il ne peut structurellement pas devenir.

Le contexte, c'est le projet

Voici ce qui est réellement difficile à capturer, et ce qui compte le plus selon nous : l'état réel d'un projet, à un instant donné, n'est pas un document. C'est du contexte. C'est la somme accumulée, éparpillée, en perpétuel mouvement, de tout ce qui a été dit, décidé, livré, retardé, modifié — et qui, pour l'essentiel, n'a jamais été noté quelque part qu'un système puisse lire.

Les outils traditionnels essaient de capturer un instantané : le planning du jour, le budget du jour, les réserves du jour. Mais la santé d'un projet n'est pas vraiment un instantané — c'est l'histoire de comment on en est arrivé là, et ce qui s'accumule discrètement sous la surface :

• Le retard qui n'apparaît pas encore dans le planning, parce que tout le monde espère encore l'absorber.
• La relation avec un sous-traitant qui se dégrade, appel manqué après appel manqué.
• Trois petits problèmes sur le même lot qui, ensemble, forment en réalité un seul gros problème que personne n'a encore nommé.

C'est presque impossible à capturer avec les outils que le secteur utilise depuis trente ans, parce que ces outils exigent que quelqu'un le remarque, décide que ça compte, et le saisisse manuellement. Le contexte résiste à ce type de capture volontaire et structurée. Il faut le saisir au moment où il se produit, sous la forme qu'il prend naturellement.

Une interface qui s'adapte au chantier, pas l'inverse

Ce qui nous amène à la deuxième idée fondatrice : l'interface doit être quelque chose que les gens savent déjà utiliser, sans avoir à y réfléchir.

Sur un chantier, presque tout le monde — du chef de chantier au chef d'équipe de soixante ans jusqu'au nouvel apprenti — sait déjà envoyer une photo et un message de deux lignes sur WhatsApp. Personne n'a eu besoin d'être formé. Personne ne doit se souvenir d'un identifiant pour un système qu'il ouvre deux fois par mois. Ce n'est pas un détail de confort ; c'est tout l'enjeu. Chaque outil supplémentaire, chaque étape en plus, chaque « merci de le noter aussi dans l'appli » est une taxe qui se paie en silence — les gens arrêtent tout simplement de le faire.

Alors, plutôt que de demander au chantier d'adopter une nouvelle discipline, Biilby adopte celle qui existe déjà. Il vit dans la même communication informelle et éparpillée, basée sur le chat, qui a déjà lieu — et il la laisse rester exactement aussi désordonnée qu'elle l'est naturellement.

Faire parler le chaos

C'est ici que l'IA fait le vrai travail, et c'est là, selon nous, que se trouve le véritable déblocage. Les grands modèles de langage sont, pour la première fois, réellement bons dans exactement la tâche que ce problème exige : lire une communication humaine éparpillée, informelle, incomplète, mal écrite, dépendante du contexte — et en extraire ce qu'elle veut vraiment dire.

Cette capacité change la donne. Il n'est plus nécessaire que le chantier structure lui-même son information pour qu'un système la comprenne — le système peut faire cette traduction lui-même, en continu, en arrière-plan, à partir du même flux désordonné de photos, de notes vocales et de messages de deux lignes qui allait de toute façon exister.

Biilby n'essaie donc pas d'organiser le chantier. Il accepte que le chantier soit, et reste toujours, chaotique — et il vit dans ce chaos plutôt que de se tenir en dehors à exiger de l'ordre.

Biilby gère la complexité. Vous, vous voyez simple.

Nous pensons que c'est le seul chemin réaliste vers ce que le secteur attend depuis des décennies et n'a jamais vraiment eu : une vue permanente et vivante de l'état réel d'un projet — pas un instantané assemblé la semaine dernière, mais la réalité accumulée et à jour du chantier, toujours actuelle, parce qu'elle est construite à partir de ce que les gens étaient déjà en train de dire.

Pourquoi c'est plus important qu'il n'y paraît

Il est tentant de lire tout cela comme une histoire de productivité — moins de rapports, des réponses plus rapides, moins d'administratif. C'est vrai, mais ça sous-estime l'enjeu.

Le point le plus profond concerne le risque. La plupart des problèmes sérieux sur un chantier ne commencent pas comme des crises. Ils commencent comme un de ces mille petits problèmes — mentionné une fois, en passant, dans un message que personne n'a signalé comme important. Le temps qu'il apparaisse dans un rapport hebdomadaire, il est souvent déjà coûteux. Un outil capable d'entendre cette première mention, et de la relier aux deux autres petites mentions qui en faisaient un vrai schéma, ne fait pas que gagner du temps. Il permet de repérer les choses trois semaines plus tôt que n'importe qui d'autre — pendant qu'il était encore possible d'agir à moindre coût plutôt que dans l'urgence.

C'est le pari derrière Biilby : non pas que l'on puisse rendre un chantier ordonné, mais que ce n'est pas nécessaire. Le chaos n'a jamais été l'ennemi. Le perdre de vue, si.

Aujourd'hui, tout commence

Cela fait un moment que nous construisons cette thèse, et le produit qui va avec — dans des conversations avec des chefs de chantier, dans des pilotes, dans de longues soirées à débattre de ce que l'outil devait, ou non, demander aux gens qui l'utilisent. Aujourd'hui, le 1er juillet 2026, nous arrêtons de l'affiner en privé et commençons à le mettre sous vos yeux.

Ce blog sera l'endroit où nous réfléchirons à voix haute sur ce parcours — ce que nous apprenons sur de vrais chantiers, où la thèse tient et où elle est mise à l'épreuve, et ce que nous construisons ensuite. Considérez ce billet comme la fondation sur laquelle tout le reste s'appuiera.

Tout commence aujourd'hui. Envie de le voir sur un projet comme le vôtre ? Voir une démo.