Coder ou mourir ?
Pourquoi les architectes et ingénieurs doivent apprendre à parler le langage des algorithmes

Quand quelques scripts déplacent des milliers d’euros

Dans plusieurs études de cas, l’introduction de la détection de conflits en BIM a permis de supprimer une grande partie des erreurs découvertes sur chantier. Certaines analyses rapportent des économies pouvant atteindre une dizaine de pourcents de la valeur du contrat, simplement en résolvant les clashes dès la phase de conception et en réduisant le retravail. 

Derrière ces gains, il n’y a pas « un bouton BIM » magique, mais une combinaison de modèles paramétriques, de scripts et d’algorithmes : des lignes de code qui relient entre eux géométrie, contraintes réglementaires, coûts et performances.

Dans ce contexte, se dire « je ne suis pas fait pour coder » revient de plus en plus à accepter que d’autres écrivent les règles qui façonneront vos projets et votre quotidien de concepteur.


📝 Le code, nouveau prolongement du croquis

Pendant longtemps, le croquis et la maquette étaient les principaux médias de la pensée architecturale. Aujourd’hui, un troisième médium s’impose : le script.

Dans la recherche comme dans la pratique, des équipes utilisent déjà Rhino + Grasshopper, Ladybug Tools et des optimiseurs comme Wallacei pour générer et évaluer des centaines de variantes de morphologie urbaine ou de forme de bâtiment, en équilibrant ensoleillement, consommation énergétique et potentiel photovoltaïque.

Ce n’est plus de la science-fiction : c’est un paysage de travail qui existe déjà dans de nombreux bureaux d’ingénieurs et d’architectes.

La façade qui « négocie » avec le climat

Imaginez une façade bioclimatique définie non pas par un seul dessin figé, mais par un ensemble de paramètres :

  • pourcentage de vitrage,
  • profondeur des brise-soleil,
  • taille des percements,
  • coût maximal par m² de façade,
  • seuils de confort lumineux et thermique.

Un script paramétrique explore alors des centaines de combinaisons possibles, évalue chacune d’elles via des simulations (ensoleillement, charges, confort) et propose un ensemble restreint de solutions “intelligentes”, dans lequel l’architecte choisit en fonction du contexte, du projet, du récit.

Ce qui change, ce n’est pas seulement la forme : c’est la façon de penser la forme.

Des cas d’usage concrets dans des bureaux d'architectes et d’ingénieurs

Sans aller jusqu’à la R&D de pointe, le code rend déjà des services très prosaïques :

  • Urbanisme & gabarits
    Génération de variantes d’implantation et de volumétrie qui respectent des gabarits dérivés du CoDT ou de règlements communaux (hauteur, recul, emprise au sol), tout en testant des scénarios de densité.
  • Structure & matériaux
    Optimisation d’une trame bois ou métallique : longueur des pièces, sections, quantité de matière, en cherchant un équilibre entre performance, coût et impact carbone. 
  • Hygiène des maquettes BIM
    Des scripts qui :
    - reclassent des objets selon un système de classification,
    - nettoient des doublons,
    - standardisent noms de familles, paramètres et phases,
    - préparent la maquette pour l’export IFC ou pour le calcul.


Conseil

Ne commencez pas par « réinventer Grasshopper ».

Cherchez une "petite douleur" très concrète dans votre pratique (renommer 200 familles, générer des coupes, exporter des quantités propres, contrôler des hauteurs de garde-corps) et écrivez ou adaptez un script qui ne fait qu’une seule chose, mais la fait bien. C’est souvent suffisant pour gagner des heures… et pour donner envie d’aller plus loin.


👨‍💻 Programmer, c’est décider : rester auteur à l’ère des algorithmes

Les algorithmes qui gouvernent nos outils ne sont pas neutres. Ils embarquent des critères de qualité, des priorités et parfois des simplifications que vous ne voyez pas toujours.


Qui écrit les règles du jeu ?

Si vous ne codez pas – même un peu – quelqu’un d’autre décide à votre place :

  • quels critères d’optimisation sont pris en compte (coût ? énergie ? confort ? carbone ?),
  • quels compromis sont jugés « acceptables »,
  • quelles hypothèses simplificatrices sont faites (sur les charges, les usages, les scénarios climatiques),
  • comment vos données BIM sont stockées, transformées, compressées, parfois perdues. 

Programmer, même modestement, c’est rendre explicite ce qui est implicite : les règles de calcul, les filtres, la façon dont les modèles sont passés à la moulinette d’un logiciel.

Un enjeu de souveraineté numérique

La littérature sur le BIM insiste de plus en plus sur des notions comme interopérabilité, openBIM ou gouvernance de la donnée : formats ouverts (IFC), standards ISO 19650, plateformes de données capables de circuler entre outils. 

La programmation devient alors un levier de souveraineté numérique :

  • vérifier les résultats d’un logiciel propriétaire,
  • extraire vos données d’un écosystème fermé,
  • automatiser vos propres contrôles de qualité,
  • connecter BIM, SIG, calculs et reporting sans dépendre d’un seul éditeur.

⚠️ Attention

Le principal risque n’est pas que « l’IA remplace l’architecte », mais que les règles du jeu soient écrites sans vous.

Un bureau 100 % dépendant d’outils propriétaires, sans capacité minimale à auditer ni à reconnecter ses données, se met dans une position de dépendance stratégique : difficile de changer de logiciel, de contester un résultat, ou d’explorer d’autres façons de travailler.



🔎 Trois environnements pour passer de « je subis » à « je pilote »

Bonne nouvelle : il n’est pas nécessaire d’apprendre dix langages.
Dans la plupart des bureaux d'architecture et d'ingénierie, trois familles d’outils suffisent pour couvrir une grande partie des usages.

1. Python– Le couteau suisse des données et de l’automatisation

Python est partout : dans de nombreux outils de calcul, dans des librairies OpenBIM (IfcOpenShell), dans des scripts de traitement de données, dans l’IA générative.

Quelques usages typiques pour un bureau :

  • extraction et filtrage de données IFC ou Revit (surfaces, quantités, typologies),
  • génération de rapports graphiques (PDF, tableurs, tableaux de bord),
  • automatisation de tâches répétitives (renommer, reclasser, regrouper),
  • connexion à des APIs (SIG, bases de prix, outils de calcul, plateformes de suivi).

2. Programmation visuelle paramétrique – Grasshopper, Dynamo & co.

Grasshopper pour Rhino, Dynamo pour Revit, et leurs cousins, sont devenus des standards de fait pour la programmation visuelle en architecture et ingénierie.

Ils permettent :

  • de manipuler des géométries complexes en restant dans un environnement graphique,
  • de brancher des moteurs de simulation (ensoleillement, flux, structure),
  • d’ajouter des optimiseurs comme Galapagos (mono-objectif) ou Wallacei (multi-objectif) pour explorer automatiquement un espace de solutions. 

Pour beaucoup de designers, c’est la porte d’entrée la plus naturelle vers le code.

3. Les scripts BIM & plateformes de données – Revit API, BlenderBIM, Speckle…

À un moment, il faut descendre au niveau de la donnée BIM elle-même :

  • automatiser des contrôles de modèles,
  • générer des vues, feuilles, nomenclatures,
  • synchroniser un modèle avec un SIG ou un outil de calcul externe.

C’est le rôle :

  • des APIs BIM (Revit API, BlenderBIM, etc.), 
  • et de plateformes comme Speckle, qui sert de couche de données ouverte entre différents logiciels (Revit, Rhino, Grasshopper, QGIS, etc.), déployée aujourd’hui comme infrastructure de données dans des centaines de bureaux à l’échelle internationale.


Focus local — Wallonie / Belgique

En Belgique, l’usage du BIM n’est pas encore légalement obligatoire, mais l’écosystème se structure rapidement : BIM Framework belge, protocoles nationaux, Wiki ISO 19650, initiatives Digital Wallonia, formations et clusters « Digital Construction ». 
En parallèle, au niveau européen, des guides sur les permis de bâtir digitaux insistent de plus en plus sur des flux BIM + SIG normalisés. 

Dans ce contexte, des compétences même modestes en scripting (contrôles automatisés, export vers IFC, connexion à une plateforme de données type Speckle) deviennent un atout concret pour répondre aux futurs appels d’offres publics et aux exigences de traçabilité.



❌ Les limites et les pièges : coder n’est pas tout maîtriser

Avant d’imaginer que le code règlera tout, il faut en reconnaître les angles morts.

1. Un mauvais script peut amplifier les erreurs

Un script mal conçu peut :

  • propager une mauvaise hypothèse dans toute une maquette,
  • supprimer ou renommer des objets de manière irréversible,
  • générer des résultats biaisés que personne ne remet en question.

D’où l’importance de :

  • versionner les scripts,
    les tester sur des modèles de copie,
    documenter ce qu’ils font, ce qu’ils ne font pas, et leurs hypothèses.

2. La documentation, parent pauvre des bureaux

Les études de cas sur le BIM et l’automatisation le répètent : la technologie n’est pas le principal frein ; ce sont l’organisation, la documentation et la transmission des pratiques.

Sans un minimum de :

  • guides internes,
  • conventions de nommage,
  • exemples pédagogiques,

les scripts deviennent vite des artefacts personnels, incompréhensibles dès que leur auteur quitte le bureau.

3. L’obsolescence des compétences

Les travaux sur les compétences numériques montrent que la durée de vie d’un stack technique se compte parfois en quelques années, voire moins dans certains domaines (IA, cloud, outils SaaS).

La bonne nouvelle, c’est que :

  • les concepts (données structurées, interopérabilité, optimisation multi-objectif, scripts reproductibles) sont plus stables que les outils,
  • apprendre à coder dans un contexte d'architectes ou d'ingénieurs, c’est d’abord acquérir ces réflexes de structuration qui resteront valables au-delà de l’outil du moment.

 À retenir

Le code n’est ni une baguette magique, ni un gadget pour geeks.
C’est un outil de pensée qui oblige à expliciter les hypothèses, les règles, les critères de choix. Utilisé avec mesure, il augmente la qualité de vos projets et votre capacité à vous adapter – sans remplacer le jugement, l’expérience ni la responsabilité de l’auteur de projet.


🧭 Conclusion — Coder pour rester vivant dans un monde algorithmique

« Coder ou mourir ? » La formule est volontairement provocatrice. Mais la tendance est claire :

  • la conception devient algorithmique,
  • les décisions de projet s’appuient de plus en plus sur des modèles et des scripts,
  • la valeur d’un bureau ne réside plus seulement dans la production de plans, mais dans sa capacité à orchestrer des flux de données.

Les architectes et ingénieurs qui sauront :

  • comprendre ce que font les algorithmes,
  • modifier ou écrire des scripts simples,
  • connecter leurs modèles à d’autres systèmes,

ne remplaceront pas les autres.
Ils deviendront les auteurs du cadre dans lequel les autres travailleront.

À l’inverse, se tenir à distance du code, c’est prendre le risque de devenir simple utilisateur de boîtes noires, dans un métier où la responsabilité, elle, reste très humaine.


💬Et maintenant ?

  1. Quelles sont les trois tâches les plus répétitives dans votre pratique actuelle qui pourraient être automatisées par un script (ou un flux paramétrique) dans les 12 prochains mois ?
  2. Qui écrit aujourd’hui les règles de calcul, de contrôle ou d’optimisation que vous appliquez sans toujours les voir – éditeurs, consultants, développeurs internes ?
  3. Si votre bureau maîtrisait ne serait-ce que 10 à 20 % de code en plus (scripts, paramétrique, automatisation BIM), quels types de projets ou d’offres nouvelles pourriez-vous proposer à vos clients publics et privés ?
  4. À l’inverse, que se passe-t-il si, dans 5 ans, vos concurrents ont structuré leurs flux de données… et pas vous ?


Références & liens utiles

Design paramétrique & optimisation en conception architecturale et structurelle

Automatisation & scripts : gains de temps et fiabilité

BIM, clash detection & ROI

Ladybug Tools – analyses environnementales open source

Grasshopper, Dynamo & optimisation (Galapagos, Wallacei)

Python & OpenBIM (IfcOpenShell, OSArch)

Speckle & outils open source pour l’interopérabilité

BIM en Belgique & cadres réglementaires émergents


Lire tous nos articles sur le numérique...

Cet article est issu d'une collaboration entre intelligence humaine et intelligence artificielle, pour explorer ensemble l’avenir de la conception architecturale.

Cet article est réalisée dans le cadre du projet Construction du Futur soutenu par Digital Wallonia (Agence du Numérique)


Partenaires du projet Construction du Futur : Buildwise, Union Wallonne des Architectes, Embuild Wallonie, Centre de Recherches Routières,  CAP Construction, Infopole et GreenWin

Encore une question ?

Le service des facilitateurs numériques de l'UWA est un projet mené avec le soutien et à l’initiative de la Wallonie.

Pour toute question complémentaire, n'hésitez pas à nous contacter à l'adresse numerique@uwa.be 

 

Virage Digital - Des auteurs de projets témoignent
Architectes et ingénieurs à l’ère numérique : 8 transitions digitales qui changent la donne