J'ai demandé à GPT-4 si un balcon était sûr. Il a dit oui. La physique a dit qu'il s'effondrerait.

Il y a un rendu sur mon bureau — une impression papier, en réalité, parce que je voulais le fixer sans écran entre nous — d'un balcon en porte-à-faux. Des lignes épurées, un garde-corps paramétrique, le genre de chose qu'on verrait dans un reportage de magazine d'architecture sur « l'avenir de la vie urbaine ». J'ai soumis l'image à GPT-4V et posé une question simple : Cette structure est-elle sûre ?

La réponse était fluide, assurée et détaillée. Elle a noté la hauteur apparente du garde-corps, commenté les conditions d'appui visibles, et conclu que la conception « semble structurellement saine, avec un support adéquat ».

J'ai ensuite montré le même plan à mon ingénieure en structures. Elle l'a regardé pendant environ quinze secondes. « Il n'y a pas de renfort de contre-portée », a-t-elle dit. « Le moment à l'encastrement dépasse la capacité de la section. Ça s'effondre. »

L'IA a vu des pixels. Elle a vu de la physique. Et cet écart — entre ce qui semble sûr et ce qui est sûr — est la raison pour laquelle j'ai fondé Veriprajna.

La séduction du « suffisamment bon »

Je dois être honnête sur un point. Quand les LLM multimodaux ont commencé à traiter des plans d'ingénierie, j'étais enthousiaste. Vraiment enthousiaste. Je me souviens d'être assis dans notre petit bureau tard un soir, à faire passer plan après plan dans les premiers accès à GPT-4V, à le regarder décrire des éléments structurels avec un vocabulaire surprenant. « Poutre en I en acier », disait-il. « Colonne en béton armé ». On aurait dit qu'il comprenait.

Cet enthousiasme a duré environ trois semaines.

Le tournant a été un test que nous avons mené sur des détails d'assemblage — les jonctions où les poutres rencontrent les colonnes, là où le transfert de charge se produit réellement. Nous avons soumis au modèle une série de plans où certains assemblages étaient correctement détaillés et d'autres présentaient des défauts subtils mais critiques : plaques de raidissement manquantes, soudures sous-dimensionnées, chemins de charge discontinus. Le genre de choses qui distingue un bâtiment qui tient debout d'un bâtiment qui s'effondre.

La précision du modèle pour identifier ces défauts était essentiellement aléatoire. Il pouvait nommer les composants. Il pouvait décrire ce qu'il voyait. Mais il ne pouvait pas raisonner sur le fait que les forces circuleraient réellement du point A au point B. C'était comme demander à quelqu'un qui aurait mémorisé le nom de chaque os du corps humain de pratiquer une opération chirurgicale.

Une IA capable de nommer chaque élément structurel mais incapable de tracer un chemin de charge n'est pas un outil d'ingénierie. C'est une responsabilité juridique dotée d'une voix assurée.

Pourquoi les LLM voient-ils les plans comme une soupe de pixels ?

Voici ce qui se passe réellement sous le capot, et cela compte même si vous n'êtes pas technicien.

Quand GPT-4V ou Gemini « regarde » un plan structurel, il utilise ce qu'on appelle un Vision Transformer. Le modèle découpe l'image en une grille de petits blocs — typiquement 16×16 pixels chacun — et les traite comme une séquence, un peu comme il traite les mots d'une phrase. Il apprend des associations statistiques entre les blocs. Un bloc contenant une ligne verticale (colonne) a tendance à apparaître près d'un bloc contenant une ligne horizontale (poutre). Sur des millions d'images d'entraînement, ces corrélations finissent par s'ancrer.

Mais voici la distinction cruciale : corrélation n'est pas causalité. Le modèle apprend que les colonnes et les poutres ont tendance à apparaître ensemble. Il n'apprend pas que la poutre est soutenue par la colonne. Il ne sait pas que si l'on retire la colonne, la poutre tombe. Il n'a pas de moteur physique interne. Il a des statistiques de motifs.

Des recherches présentées à NeurIPS ont démontré quelque chose qui devrait alarmer quiconque envisage de déployer ces modèles pour des tâches critiques en matière de sécurité : quand on brouille les blocs de pixels d'une image — littéralement en les mélangeant comme un jeu de cartes — les Vision Transformers conservent souvent une précision de classification élevée. Ils ne lisent pas la structure spatiale. Ils lisent la texture et les motifs locaux.

En ingénierie, la structure spatiale est primordiale. Un détail d'assemblage qui est « presque complet » mais auquel il manque un chemin de charge critique n'est pas sûr à 90 %. Il est dangereux à 100 %.

Que se passe-t-il quand on évalue réellement les LLM sur le raisonnement structurel ?

J'ai continué à espérer que les benchmarks me donneraient tort. Ce ne fut pas le cas.

L'étude DSR-Bench a évalué dix LLM de pointe sur 4 140 instances de problèmes conçues pour tester le raisonnement structurel — la capacité à comprendre et à manipuler des relations complexes entre entités. C'est exactement ce dont on a besoin pour analyser l'ossature d'un bâtiment : tracer des relations à travers de multiples nœuds, satisfaire des contraintes strictes, raisonner sur des configurations spatiales.

Le meilleur modèle de pointe a obtenu un score de 0,498 sur 1,0 sur les instances difficiles. Essentiellement un tirage à pile ou face.

Les modes d'échec étaient précis et accablants. Le raisonnement multi-sauts — tracer une relation à travers plusieurs nœuds intermédiaires, ce qui correspond littéralement à ce qu'exige l'analyse du chemin de charge — constituait une faiblesse constante. Et la performance se dégradait lorsque les problèmes étaient décrits en langage naturel plutôt qu'en code formel, ce qui suggère que les modèles faisaient de la reconnaissance de motifs syntaxiques issus de leurs données d'entraînement plutôt qu'un véritable raisonnement.

Je me souviens de la réunion d'équipe où nous avons passé en revue ces chiffres. Un de mes ingénieurs, prudemment optimiste quant à l'utilisation des LLM comme outil de premier tri, est resté silencieux un long moment. Puis il a dit : « Donc, quand un ingénieur décrit un problème structurel non standard en langage courant, le modèle devine essentiellement une fois sur deux. » C'est à ce moment-là que la salle a basculé. Pas progressivement — d'un coup.

Par ailleurs, le benchmark DesignQA a révélé que les LLM multimodaux pouvaient répondre à « Quelle est la flèche maximale autorisée ? » (extraire un chiffre de la documentation) mais échouaient sur « Cette conception de poutre spécifique respecte-t-elle la flèche maximale autorisée ? » (appliquer ce chiffre à un visuel). Extraction contre application. Connaître la règle contre la faire respecter.

J'ai décrit ce mode d'échec beaucoup plus en détail dans la version interactive de notre étude, y compris les biais bizarres de sélection des matériaux que nous avons découverts — des LLM recommandant du titane et de la fibre de carbone pour des contextes qui appelaient manifestement de l'acier de construction standard, simplement parce que les matériaux exotiques dominent les recoins « high-tech » de leurs données d'entraînement.

Le moment où nous avons cessé d'essayer de corriger les LLM

Il y a eu une réunion avec des investisseurs — je ne dirai pas laquelle — où quelqu'un a regardé nos premières recherches et a dit : « Pourquoi ne pas simplement affiner (fine-tune) GPT pour l'ingénierie des structures ? Ça semble être la voie la plus rapide. »

Je comprenais la logique. Prendre le paradigme dominant, le spécialiser, le lancer. Mais j'avais étudié ce problème assez longtemps pour savoir qu'affiner un modèle probabiliste pour effectuer un travail déterministe revient à affiner un poète pour faire de l'arithmétique. On peut le pousser à produire des chiffres. On ne peut pas le forcer à garantir que ces chiffres sont exacts.

Les lois de la physique ne sont pas probabilistes. Si la somme des forces s'exerçant sur un élément structurel n'est pas égale à zéro, l'élément accélère. Il n'y a pas de « généralement » qui tienne. Il n'y a pas d'intervalle de confiance. L'équation de poutre d'Euler-Bernoulli se moque de la distribution de vos données d'entraînement.

Nous avons donc pris une décision qui semblait à contre-courant à l'époque et qui paraît évidente aujourd'hui : nous avons entièrement abandonné l'image.

Pas l'IA — l'image. Nous avons cessé d'essayer de faire comprendre aux réseaux de neurones les plans en tant qu'images. Nous avons plutôt commencé à convertir les bâtiments en ce qu'ils sont réellement : des graphes mathématiques.

Un bâtiment n'est pas une image. C'est un réseau de forces. Dès l'instant où on le traite comme des pixels, on a déjà perdu la physique.

Comment transformer un bâtiment en graphe ?

Un graphe, au sens mathématique, n'est rien d'autre que des nœuds et des arêtes. Les nœuds sont des choses ; les arêtes sont des connexions entre ces choses.

Dans notre système, chaque composant structurel — poutre, colonne, dalle, mur — devient un nœud. Mais contrairement à un pixel, qui ne porte que des données de couleur, chacun de nos nœuds porte un vecteur de caractéristiques riche : le module d'Young (la rigidité du matériau), le moment d'inertie (la résistance de la section à la flexion), la limite d'élasticité (le point de rupture du matériau). Les paramètres physiques réels dont on a besoin pour calculer si quelque chose tient debout ou s'effondre.

Chaque connexion physique entre composants devient une arête. Une arête entre une poutre et une colonne capture la rigidité de la connexion — s'agit-il d'une liaison rigide résistant au moment ou d'une simple articulation ? — ainsi que l'orientation relative. Ce ne sont pas des approximations apprises. Elles sont extraites directement des données BIM (Building Information Modeling), où la connectivité est explicitement définie.

Cette représentation possède une propriété d'une importance considérable : l'invariance par permutation. La physique d'un bâtiment ne change pas si l'on réordonne la liste des poutres dans la base de données. Les réseaux de neurones sur graphes respectent cela. Les LLM à base de Transformer, qui traitent des séquences, sont sensibles à l'ordre des données d'entrée. Cela ressemble à un détail technique, mais c'est la différence entre une architecture alignée sur le problème et une architecture qui lutte contre lui.

Nous avons construit un pipeline qui prend des fichiers IFC — le format standard pour les données BIM — et les convertit en graphes de calcul. Là où un LLM essaierait de « lire » l'image du plan et de deviner les connexions, notre analyseur capture la connectivité avec une fidélité de 100 % parce que le schéma IFC la définit explicitement. Aucune supposition. Pas de « on dirait que ces éléments sont connectés ». Soit ils le sont, soit ils ne le sont pas.

Le moment où nous avons enseigné la physique aux réseaux de neurones

C'est là que ça devient intéressant, et là où je pense que nous faisons quelque chose de vraiment différent.

L'apprentissage automatique standard fonctionne ainsi : montrer au modèle une multitude d'exemples, le laisser apprendre des motifs, espérer qu'il généralise. Le problème en ingénierie des structures, c'est qu'« espérer qu'il généralise » n'est pas une norme de sécurité acceptable.

Les réseaux de neurones informés par la physique — PINN — adoptent une approche fondamentalement différente. Plutôt que de demander à l'IA de découvrir la physique à partir des données, nous intégrons les équations régissant le phénomène directement dans la fonction de perte du réseau. La fonction de perte est ce que le réseau cherche à minimiser pendant l'entraînement — c'est la définition de « faux » qui guide l'apprentissage.

Dans un réseau de neurones standard, « faux » signifie « votre prédiction ne correspond pas aux données d'entraînement ». Dans un PINN, nous ajoutons une seconde définition de « faux » : « votre prédiction viole les lois de la physique ».

Prenons l'équation de poutre d'Euler-Bernoulli, qui régit la manière dont une poutre fléchit sous charge. Quand notre réseau prédit la forme de déflexion d'un élément structurel, nous utilisons la différentiation automatique pour calculer le résidu physique — ce qui revient à demander : « Cette déflexion prédite satisfait-elle l'équation différentielle de l'équilibre statique ? » Si ce n'est pas le cas, le terme de perte physique s'envole, et le réseau est contraint de se corriger.

Le réseau ne peut littéralement pas apprendre une solution qui viole les lois de Newton. Pas « ne le fera probablement pas ». Ne le peut pas.

Je me souviens de la première fois où nous avons réussi à faire fonctionner cela sur une structure non triviale. Nous nous étions débattus pendant des semaines avec des problèmes de convergence — la perte physique et la perte liée aux données se combattaient, et le réseau oscillait. Mon ingénieur ML principal dormait au bureau (je lui avais dit de ne pas le faire ; il m'a ignoré). Puis, un matin, il m'a appelé devant son écran. Les courbes de déflexion prédites s'étaient parfaitement alignées sur la solution obtenue par MEF (méthode des éléments finis). Pas approximativement. La valeur du R² était de 0,9999.

Nous avions construit quelque chose qui avait la vitesse de l'IA et la précision des solveurs d'ingénierie traditionnels. Des recherches récentes sur les DeepONets structurés en graphe et informés par la physique — la classe d'architecture sur laquelle nous nous appuyons — ont démontré des accélérations de 7 à 8 fois par rapport à la MEF traditionnelle, tout en conservant ce niveau de précision. Pour l'analyse technique complète de notre architecture et de nos benchmarks, y compris les mathématiques derrière notre cadre de passage de messages (message-passing), j'ai publié un article de recherche détaillé.

Peut-on réellement voir où un bâtiment va céder ?

C'est la question qui préoccupe le plus les ingénieurs, et c'est là que l'analyse par graphe devient viscéralement puissante.

Dans notre système, nous ne nous contentons pas de vérifier si une structure réussit ou échoue dans son ensemble. Nous traçons le chemin de charge principal — le trajet emprunté par les forces depuis le point d'application (disons, des personnes debout sur un balcon) jusqu'aux fondations, en traversant la structure.

Nous procédons ainsi grâce à une métrique appelée l'indice U*, qui cartographie le transfert interne d'énergie de déformation et la rigidité relative entre les points. En utilisant l'intégration de Runge-Kutta sur le gradient U*, nous traçons des « lignes de courant » de force à travers la structure — comme une carte météo, mais pour les charges plutôt que pour le vent.

Quand une structure est sûre, les lignes de courant s'écoulent de manière continue depuis l'élément chargé jusqu'aux fondations. Quand ce n'est pas le cas — quand il manque une connexion, qu'un élément est sous-dimensionné, que le chemin de charge est discontinu — les lignes de courant s'interrompent brutalement ou divergent violemment.

Revenons à ce rendu de balcon sur mon bureau. Quand nous l'avons fait passer dans notre pipeline de graphe, la ligne de courant du chemin de charge issue de la dalle en porte-à-faux s'est simplement... arrêtée. Il n'y avait aucune connexion de contre-portée pour transférer le moment vers la structure porteuse. Le contour U* montrait une concentration massive d'énergie de déformation à l'encastrement, sans aucune issue. La visualisation rendait le mode de défaillance évident, d'une manière qu'aucune analyse de pixels n'aurait jamais pu égaler.

Une ligne de courant du chemin de charge qui s'interrompt est une phrase que la structure écrit sur sa propre mort. Il suffit de savoir lire le graphe.

Nous pouvons également simuler un effondrement progressif — ce qui se passe quand on retire une colonne et qu'on se demande « le reste de la structure tient-il ? » — en supprimant systématiquement des nœuds du graphe et en réévaluant la connectivité. À l'aide de mesures comme la centralité d'intermédiarité (Betweenness Centrality), nous identifions des groupes critiques de composants dont la défaillance scinderait le graphe en morceaux déconnectés. Cette simulation « d'attaque de graphe » s'exécute en quelques secondes. L'analyse d'effondrement par MEF non linéaire équivalente prend des heures. Nous pouvons passer en revue des milliers de scénarios de défaillance avant qu'un ingénieur ait fini son café.

Pourquoi ne pas simplement utiliser les deux ? La couche de vérification

On me le fait toujours remarquer. « Ashutosh, l'IA générative est incroyable pour la conception en phase initiale. On ne peut pas simplement l'ignorer. » Et ils ont raison — je ne veux pas l'ignorer. Que des architectes utilisent des outils comme Midjourney ou des générateurs paramétriques pour explorer des concepts créatifs, c'est réellement passionnant. Le problème n'est pas la génération. C'est la vérification.

Ce que nous avons construit, c'est une couche de vérification. Le modèle génératif propose une conception. Veriprajna la convertit en graphe, vérifie la connectivité topologique, trace le chemin de charge, exécute la prédiction informée par la physique. Si le contrôle physique échoue, nous renvoyons une contrainte stricte — pas une suggestion, une contrainte : « Augmenter la hauteur de la poutre de 200 mm » ou « Ajouter une connexion de contre-portée ». Le modèle génératif régénère alors dans ces limites.

Une créativité contrainte par la physique. Une imagination vérifiée par les mathématiques. C'est ça, le flux de travail.

Et parce que nos modèles sont contraints par des équations physiques plutôt qu'entraînés sur l'intégralité d'internet, ils sont remarquablement efficaces en données. Un PINN entraîné sur des ossatures en acier se généralise à de nouvelles ossatures en acier, parce que la loi de Hooke ne change pas d'un projet à l'autre. Cela signifie aussi que les modèles sont suffisamment petits pour être déployés sur site (on-premise). Aucun client n'a besoin d'envoyer les plans d'infrastructures sensibles vers une API publique.

La boîte de verre contre la boîte noire

Il y a encore une chose qui m'empêche de dormir à propos des outils d'ingénierie basés sur les LLM, et ce n'est pas la précision — c'est l'explicabilité.

Quand un réseau de neurones sur graphes formule une prédiction concernant un élément structurel, nous pouvons visualiser exactement quels nœuds voisins ont influencé cette prédiction, grâce aux poids d'attention. « La colonne a été signalée parce que la charge combinée transférée par les poutres A et B dépassait sa capacité. » C'est une chaîne de raisonnement traçable et auditable. Un ingénieur peut l'examiner et dire : « Oui, c'est correct » ou « Non, vous avez mal calculé la surface tributaire ». Il peut débattre avec le modèle.

Essayez de débattre avec le raisonnement de GPT-4 sur une évaluation structurelle. Demandez-lui pourquoi il a conclu que le balcon était sûr. Vous obtiendrez un paragraphe fluide, qui semble raisonnable, mais qui ne correspond à rien de vérifiable. Le raisonnement est réparti à travers des milliards de paramètres, d'une manière qu'aucun humain ne peut inspecter.

En logiciel, une boîte noire est un choix de conception. En ingénierie des structures, une boîte noire est une démission de responsabilité.

La question des fondations

J'ai passé assez de temps dans des salles de conférence et des réunions avec des investisseurs pour savoir que l'engouement actuel pour l'IA dans la construction porte presque entièrement sur les modèles génératifs. Les présentations sont magnifiques. Les démonstrations sont impressionnantes. L'hypothèse sous-jacente — selon laquelle on peut prédire la sécurité structurelle à coups de pixels — est fausse.

L'industrie de la construction se distingue de toutes les autres industries sur un point crucial : nos bugs tuent des gens. Un bug logiciel se corrige par un correctif. Un bug structurel donne lieu à une enquête sur un effondrement, un procès, un mémorial. La marge pour « probablement correct » est nulle.

Nous avons construit Veriprajna sur la théorie des graphes, l'apprentissage profond géométrique et les équations différentielles, parce que ce sont les seuls fondements qui offrent des réponses déterministes aux questions de sécurité. Pas « ça a l'air sûr ». Pas « d'après des structures similaires dans nos données d'entraînement, c'est probablement adéquat ». Mais : le résidu physique est nul, le chemin de charge est continu, la contrainte reste dans la capacité admissible.

GPT-4 m'a dit que ce balcon était sûr parce qu'il avait vu des milliers de photos de balcons, et que sur ces photos, les pixels du sol du balcon restaient généralement au-dessus des pixels du sol au niveau du terrain. La physique m'a dit qu'il s'effondrerait parce que le moment de flexion à l'encastrement dépassait la capacité de moment de la section.

Je sais sur lequel des deux je construis.