Le problème : l'auto-validation optimiste

Un agent IA peut écrire qu'une tâche est terminée avec beaucoup d'assurance. Il peut avoir produit du code cohérent, proposé une correction plausible et même décrit les tests qu'il pense avoir lancés. Pourtant, entre « le correctif est prêt » et « le correctif a été exécuté, observé et relu », il existe un écart important.

Cet écart ne concerne pas seulement les agents. Il apparaît chaque fois qu'une équipe perd le fil entre une affirmation, la commande réellement exécutée, sa sortie et la personne qui a relu le résultat. Dans un workflow technique, une phrase rassurante ne doit pas remplacer la trace de ce qui s'est passé.

C'est le point de départ de WinCreator : demander qu'une affirmation technique importante soit reliée à une preuve observable avant de la présenter comme terminée. Le projet est open source et son dépôt public est disponible sur GitHub.

Un registre de preuve plutôt qu'un discours

WinCreator utilise un Proof Ledger en Markdown. Le registre donne un endroit explicite à l'affirmation : ce qui est annoncé, le niveau de contrôle demandé, la commande associée, la capture disponible et le verdict de revue. Le but n'est pas de transformer toute tâche en procédure lourde. Le but est d'éviter qu'une information critique se dissolve dans l'historique d'un chat ou dans une succession de messages.

Une preuve peut comprendre la commande exécutée et sa sortie capturée. Des attestations relient les captures aux affirmations concernées. Cela rend la discussion plus concrète : au lieu de débattre de ce que l'agent dit avoir fait, une équipe peut examiner ce qui est inscrit, capturé et revu.

Le registre n'est pas un score de qualité magique. Il ne détermine pas que la bonne règle a été choisie ni qu'un résultat est adéquat dans son contexte. Il prépare simplement une base de revue plus nette.

Builder et Reviewer : séparer deux responsabilités

La méthode distingue le Builder, qui réalise et capture le travail, du Reviewer, qui examine ce qui est présenté. Cette séparation compte particulièrement dès qu'une tâche présente un risque : la même boucle ne devrait pas produire la preuve, interpréter seule cette preuve et prononcer son propre verdict.

WinCreator propose trois niveaux. Lite convient à une boucle légère et peut automatiser l'approbation. Standard introduit une revue séparée. Regulated ajoute des exigences de séparation et de contrôle plus strictes, notamment autour de l'état du travail à examiner. Le niveau ne remplace pas le jugement : il rend le degré de vigilance attendu visible dès le départ.

Un exemple dans un contrôle BIM

Prenons un contrôle IFC simple. Une équipe peut demander : « tous les équipements concernés doivent porter une classification et une propriété de localisation ». Un agent peut générer ou exécuter un script qui liste les objets non conformes. Sans trace, il est facile de conclure trop vite : « le contrôle est fait ».

Avec une logique de preuve, l'affirmation devient plus précise : le script a été exécuté sur tel export, avec telles règles ; la sortie a été capturée ; un reviewer vérifie que le périmètre, les objets traités et l'interprétation correspondent réellement au besoin. Le résultat ne rend pas la maquette automatiquement conforme. Il rend la vérification plus facile à inspecter et à rejouer.

C'est le lien naturel avec l'audit IFC. Dans une maquette, une affirmation comme « les classifications sont prêtes » doit être confrontée aux objets, aux propriétés et au livrable. Dans un workflow agentique, une affirmation comme « le correctif est terminé » doit être confrontée aux commandes, sorties et revues. Dans les deux cas, une affirmation ne vaut pas encore une preuve.

Confidentialité, redaction et limites

Une capture peut contenir des chemins locaux, des identifiants, des données de projet ou des sorties trop volumineuses. WinCreator documente des contrôles de redaction, des limites de sortie et des captures privées. Ces mécanismes réduisent l'exposition accidentelle ; ils ne dispensent pas une équipe de choisir soigneusement les données qu'elle fait circuler.

Le projet propose aussi un mécanisme HMAC. Il peut aider une personne qui détient la clé à détecter qu'une trace a été modifiée. Il ne s'agit pas d'une signature publique et ce n'est pas un registre de transparence indépendant. Le détenteur de la clé n'est pas un tiers de confiance extérieur : cette limite doit rester explicite.

WinCreator ne rend pas une IA infaillible. Il ne certifie pas automatiquement un résultat, ne remplace pas un audit humain et ne garantit pas la conformité réglementaire. Il impose une question plus saine : quelle preuve soutient exactement cette affirmation, et qui l'a examinée ?

Un projet ouvert, destiné aux workflows techniques

La version publique 3.0.0 est distribuée sous licence MIT. Le dépôt documente un package installable, la compatibilité Python 3.10 à 3.13, des tests Ubuntu, Windows et macOS, ainsi que des validations Skill Creator et Agent Skills. Ces éléments ne mesurent pas une adoption ni une qualité universelle ; ils permettent de voir clairement ce que le projet déclare et comment il est structuré.

WinCreator n'est pas un produit BIM ni un SaaS. C'est un outil open source pour les développeurs, les équipes techniques et les workflows d'agents. Son intérêt pour BIMCheck tient à une conviction commune : lorsqu'une donnée ou une tâche compte, il faut pouvoir montrer pourquoi on lui fait confiance.

Pour examiner le projet, consulter la release v3.0.0, la licence MIT et le dépôt source.

Une innovation utile reste vérifiable

Dans le BIM comme dans le développement logiciel, une nouveauté ne vaut pas par son vocabulaire mais par la possibilité de la comprendre, de l'essayer et d'en examiner les limites. Une méthode ouverte permet de séparer plus facilement ce qui est réellement observé, ce qui est déduit et ce qui reste à faire vérifier par un professionnel. Cette distinction est particulièrement utile lorsqu'un agent participe à une tâche technique.

Garder la responsabilité humaine visible

Un outil peut produire une trace, appliquer une règle ou faciliter une revue. Il ne décide pas seul que le contexte métier est correct, que l'exigence est suffisante ou qu'un livrable est accepté. L'innovation la plus utile n'efface pas cette responsabilité : elle aide les équipes à voir les preuves, à discuter les écarts et à mieux documenter la décision finale.

Checklist rapide

L'usage attendu de la donnée est identifié avant le contrôle.
Les objets critiques sont typés correctement dans l'IFC.
Les propriétés demandées sont présentes, remplies et placées dans des champs cohérents.
Les classifications suisses sont lisibles et homogènes.
Les écarts sont priorisés par impact projet, pas seulement listés.
Le livrable permet une correction réelle par les équipes concernées.

Prochaine décision à prendre

Avant le prochain export IFC, il faut choisir le contrôle qui réduit vraiment le risque du projet : typage des objets, propriétés attendues, classification, localisation des actifs ou donnée de remise. Le résultat attendu n'est pas une remarque générale, mais une décision claire : corriger maintenant, suivre au prochain jalon ou accepter l'écart parce qu'il n'a pas d'impact sur l'usage prévu.

Cette logique transforme le contrôle en plan d'action. Le périmètre est vérifié, les écarts prioritaires sont isolés, les responsables de correction sont identifiés et la validation peut se faire sur un nouvel export.