Ishigaki-IDS : un modèle d'IA de 8 milliards de paramètres pour la rédaction d'IDS

AWS a dévoilé le 11 août les coulisses d'Ishigaki-IDS, un outil d'IA japonais qui rédige des fichiers IDS à partir d'un cahier des charges en texte ou en tableau. Discrètement disponible depuis mars, gratuit et téléchargeable, il produit un fichier valide deux fois plus souvent que ChatGPT ou Claude, et six praticiens testés ont mis moitié moins de temps qu'en rédaction manuelle. Le revers : parmi les fichiers qui passent le validateur officiel, près d'un quart ne vérifient pas la bonne chose. La conformité au standard ne garantit pas la conformité au besoin ; et ça change la façon dont il faut organiser la relecture.

Une sortie passée inaperçue, révélée par AWS

Le 11 août, AWS a publié un retour d'expérience technique détaillant la construction d'Ishigaki-IDS, un outil d'intelligence artificielle conçu par ONESTRUCTION, une startup japonaise spécialisée dans l'openBIM. Le modèle, lui, est en libre accès depuis le 27 mars, et deux publications scientifiques l'accompagnent depuis le printemps. C'est donc une découverte tardive plus qu'une nouveauté : l'outil est disponible depuis cinq mois sans avoir fait de bruit dans la filière.

Il est entraîné pour une seule tâche : produire des fichiers IDS à partir d'exigences d'information rédigées en langage courant ou dans un tableau.

Deux choses le distinguent des assistants IA que vous connaissez.

D'abord, il est spécialisé. Là où ChatGPT ou Claude savent un peu tout faire, celui-ci n'a été entraîné que sur du BIM, de l'IFC et de l'IDS. Sur cette tâche précise, il fait nettement mieux qu'eux.

Ensuite, il est gratuit et téléchargeable. Pas d'abonnement, pas d'envoi de vos données chez un prestataire : le programme tourne sur votre machine, et sa réutilisation est autorisée y compris en contexte commercial. À notre connaissance, c'est le premier outil de ce type dans le monde du BIM.

Le projet a été financé par un programme public japonais de soutien à l'IA, avec un accompagnement technique d'AWS.

Pourquoi l'IDS, précisément

Pour ceux qui n'ont pas encore mis les mains dedans : l'IFC décrit ce qu'est la maquette numérique, l'IDS décrit ce qu'elle doit contenir, sous une forme que la machine peut contrôler toute seule. « Tous les murs doivent porter une résistance au feu, valeur EI30, EI60 ou EI90 » : voilà une règle IDS.

C'est le chaînon entre votre cahier des charges et le contrôle qualité automatisé. Sauf que le rédiger reste ingrat. Il faut traduire chaque exigence dans le vocabulaire IFC normalisé ; un trottoir devient IfcPavement, pas IfcSlab ; puis l'encoder dans un format XML strict, et enfin passer le validateur officiel de buildingSMART, faute de quoi le fichier n'est même pas chargeable dans une chaîne de contrôle.

Beaucoup de plomberie, donc, avant d'arriver au travail qui a de la valeur : vérifier que l'exigence dit bien ce qu'on veut.

Ce que l'outil fait bien

L'évaluation porte sur 166 cas rédigés et vérifiés par des experts BIM, couvrant l'architecture, la structure, les fluides et le BIM management, sur plusieurs versions d'IFC.

Résultat : l'outil produit un fichier acceptable par le validateur officiel dans environ deux tiers des cas. La meilleure IA généraliste testée plafonne à un tiers, les autres en dessous. Ce n'est pas une amélioration marginale, c'est un rapport du simple au double.

Le test le plus parlant reste celui mené avec six praticiens BIM extérieurs au projet, dont trois n'avaient jamais rédigé d'IDS. Chacun devait produire un fichier atteignant un résultat validé, une fois à la main, une fois assisté par l'outil. Le temps de travail cumulé a baissé de 54,7 %, et les six ont tous été plus rapides avec l'assistance.

Autrement dit : la corvée technique ; le XML, la syntaxe, le débogage de schéma ; disparaît largement.

Le piège : validé n'est pas correct

C'est ici que ça se complique, et c'est la partie que la communication autour du projet met peu en avant.

Les auteurs ont regardé de près les fichiers qui passent le validateur officiel, pour vérifier s'ils correspondaient bien à l'exigence de départ. Le résultat est sévère : seuls 13 % correspondent exactement à ce qui était demandé. À l'autre bout, 60 % s'écartent suffisamment pour exiger une correction substantielle ; et dans près de la moitié de ces cas, soit 23 % du total, le fichier ne correspond tout simplement pas à la demande.

Les exemples cités par les auteurs sont éclairants. Pour une exigence portant sur un trottoir, l'outil produit une règle sur les dalles. Pour une exigence de surface au niveau du logement, il génère une condition au niveau de la parcelle. Dans les deux cas, le fichier est irréprochable au sens du standard. Il ne contrôle simplement pas ce qu'on lui avait demandé de contrôler.

Les auteurs sont honnêtes sur ce point : leur outil n'a pas vocation à remplacer la relecture par un expert. Il déplace l'effort, il ne le supprime pas.

Ce que ça change dans vos process

Trois conséquences pratiques, que vous utilisiez cet outil ou non.

Le validateur vert ne prouve rien sur le fond. C'était déjà vrai avant l'IA, mais ça devenait rarement un problème : un humain qui prenait la peine d'écrire du XML à la main savait généralement ce qu'il écrivait. Quand un fichier conforme se produit en trois secondes, le raisonnement s'effondre. Un IDS qui passe l'audit atteste de la conformité au standard, pas au besoin du projet.

Inscrivez la relecture métier au processus. Si votre organisation commence à générer des IDS assistés par IA, cette étape ne doit pas dépendre de la disponibilité de chacun. Un contrôle simple et efficace : faire relire le fichier par quelqu'un qui n'a pas rédigé l'exigence de départ, et lui demander de reformuler en français ce que ce fichier vérifie. Si sa reformulation s'écarte de l'exigence initiale, l'erreur est dans l'IDS.

Structurez vos exigences en tableau. Les tests montrent que les exigences fournies sous forme de tableau ; une ligne par exigence, avec des colonnes pour l'élément visé, la propriété attendue et la contrainte de valeur ; donnent de meilleurs résultats qu'un paragraphe de cahier des charges. C'est vrai pour la machine, et ça l'est tout autant pour vos partenaires : le tableau force à lever les ambiguïtés au moment de l'écriture, pas au moment du contrôle.

Et pour les projets francophones ?

Une réserve importante : l'outil a été entraîné en japonais et en anglais. Ses performances sur des exigences rédigées en français, avec nos conventions de nommage de propriétés et nos référentiels nationaux, restent à mesurer ; et probablement à la baisse.

Le signal le plus intéressant pour la filière n'est peut-être pas l'outil lui-même, mais ce qu'il démontre : un petit programme spécialisé, entraîné contre l'outil de contrôle officiel d'un standard, bat des IA généralistes bien plus puissantes. Notre secteur a ses normes, son vocabulaire et ses validateurs. La recette est publiée et reproductible.

Une précision enfin, cohérente avec le sujet de cet article : les résultats cités proviennent de deux publications scientifiques déposées en préprint, qui n'ont pas encore été relues par les pairs.

Sources

• Ishigaki-IDS: An Open-Weight Verifier-Aware Model for IDS Drafting in BIM ; arXiv
• Ishigaki-IDS-Bench: A Benchmark for Generating IDS from BIM Information Requirements ; arXiv
• How ONESTRUCTION built the Ishigaki-IDS foundation model with AWS GenAIIC ; AWS, 11 août 2026
• Ishigaki-IDS-8B ; Hugging Face, licence CC BY 4.0
• Information Delivery Specification (IDS) ; buildingSMART International