Il est tentant de raconter l’IA comme une rupture absolue. Ce n’est pas faux, mais c’est trop court. Les grands modèles de langage s’inscrivent dans une histoire très ancienne : celle des inscriptions, des registres, des règles, des calculs et des procédures par lesquelles les sociétés apprennent à rendre le monde manipulable.
Avant l’ordinateur, il y a déjà des bases de données au sens culturel du terme : listes mésopotamiennes, cadastres, comptabilités, archives, actes, droit romain, administrations, règles d’actualisation, identifiants, propriétés, limites et obligations. On ne calcule pas encore avec des processeurs, mais on stabilise le réel sous forme d’informations transmissibles.
Puis vient l’âge du calcul automatisé. Boulier, machines mécaniques, cryptographie, Enigma, transistor, CPU, bases de données, CAO, SIG, BIM. L’informatique déterministe explose parce qu’elle sait exécuter vite et fidèlement des opérations explicites. Elle trie, calcule, duplique, dessine, interroge, projette, simule, exporte.
L’informatique conventionnelle a industrialisé des contextes simplifiés. Les LLM ouvrent la possibilité de reconnecter l’informatique aux contextes réels.
Cette informatique classique reste pourtant prise dans une tension permanente. Elle fonctionne très bien quand les objets sont stabilisés, les règles explicites, les processus répétables, les interfaces définies. Mais le réel déborde toujours : fichiers imparfaits, conventions locales, documents ambigus, chantier incomplet, géoréférencement douteux, formats captifs, exceptions, responsabilités distribuées.
- formulaire
- bouton prévu
- format attendu
- procédure moyenne
interpréter, convertir, contourner, vérifier
- fichier incomplet
- convention locale
- document ambigu
- responsabilité partagée
Le logiciel court après les contextes réels, et les contextes réels courent après le logiciel. On ajoute des menus, des plugins, des exports, des tickets, des champs, des workflows. L’utilisateur finit souvent par faire lui-même la jonction entre ce que le logiciel permet et ce que la situation demande.
Une maquette IFC arrive avec des objets bien dessinés, mais mal situés, des niveaux incohérents ou des attributs absents. Le problème n’est pas seulement d’ouvrir le fichier : il faut comprendre ce qui est fiable, ce qui sert au projet et ce qui doit être recalé.
Une couche de voirie, un plan de réseaux et une orthophoto ne racontent pas exactement le même moment. Les afficher ensemble ne suffit pas : il faut vérifier les dates, les référentiels, l’échelle et l’usage possible.
Une règle est parfois répartie entre un PDF, une note interne, un tableau, un mail et une pratique locale. L’informatique classique exige souvent de tout ramener dans un formulaire ; le contexte réel commence avant ce formulaire.
Il y a probablement une raison économique à cette rigidité. La micro-informatique professionnelle s’est construite sur des coûts de développement élevés, des interfaces rationalisées, des formats propriétaires, des abonnements, des écosystèmes captifs et des positions dominantes. Cette stabilité a produit de la puissance et de la productivité. Elle a aussi produit de la rente.
Les LLM changent le point d’articulation. Ils ne remplacent pas les programmes déterministes. Ils rendent plus facile leur production, leur adaptation et leur orchestration. Ils lisent une situation formulée, écrivent du code, appellent des outils, inspectent des fichiers, produisent des rapports, corrigent des scripts, organisent des sorties. Le déterminisme ne disparaît pas : il devient plus local, plus ajustable, plus proche du contexte.
Finir l’informatisation
Le LLM peut donc servir à finir l’informatisation d’un geste métier. Non pas en restant branché éternellement sur chaque opération, mais en aidant à transformer une pratique floue en chaîne explicite : données d’entrée, hypothèses, formats, scripts, traitements, sorties, contrôles et limites.
“Je dois vérifier si ce projet tient dans ce territoire, avec ces données imparfaites.”
traduire la demande, lister les sources, écrire le script, tester, commenter les limites
modèle QGIS, requête SQL, script Python, procédure, journal et contrôles reproductibles
Quand cette chaîne devient mûre, elle doit pouvoir être débranchée du LLM. Elle devient script, requête SQL, modèle QGIS, validateur, procédure, interface ou documentation. Le LLM revient pour les exceptions, les évolutions, les cas nouveaux, les traductions entre contextes.
C’est particulièrement net dans les métiers BIM-SIG. Le BIM promet de relier maquette, chantier, exploitation, territoire et données. Mais l’informatique conventionnelle a souvent figé cette promesse dans des logiciels, des exports, des formats, des conventions implicites et des séquences de clics. Le LLM peut aider à transformer cette promesse en chaînes de travail plus explicites et plus vérifiables.
Une révolution des interfaces et des pouvoirs
L’interface est la première chose qui bouge. Pendant des décennies, utiliser l’informatique professionnelle a voulu dire apprendre où cliquer. Le langage devient une interface générale : décrire un besoin, demander une vérification, transformer un fichier, produire une carte, écrire une note, générer un script.
Avant : “exporter la couche, corriger à la main, refaire la carte, expliquer dans un mail”. Après : “décris la chaîne, identifie les entrées, génère le traitement, conserve le script, note les hypothèses et produit une sortie vérifiable”.
- Ce qui reste humain : formuler le problème, choisir les hypothèses, assumer l’usage.
- Ce qui devient informatique : exécuter, répéter, contrôler, documenter.
- Ce qui doit rester visible : sources, versions, limites, erreurs et responsabilités.
La distribution des traitements change aussi. On n’attend plus forcément qu’un éditeur ait prévu le bouton. Une chaîne peut être assemblée localement avec Python, GDAL, QGIS, PostGIS, IfcOpenShell, des API et des fichiers. Ce déplacement est discret, mais considérable.
La propriété des données redevient centrale. Si la chaîne fonctionne sur formats ouverts, scripts conservés et journaux lisibles, les données restent transportables et auditables. Si elle ne fonctionne que dans une plateforme fermée, l’agent intégré peut renforcer la dépendance au lieu de l’alléger.
L’optimisation change de nature. L’informatique conventionnelle impose souvent une procédure moyenne à des contextes hétérogènes. Le LLM peut aider à produire des procédures ajustées, puis à stabiliser celles qui deviennent répétables.
Le risque augmente avec la puissance
Tout cela n’est pas une promesse naïve. Plus l’information devient opérable, plus les erreurs peuvent être amplifiées. Une scène, un plan, une note, une image, une consigne, une table ou un document réglementaire peuvent être interprétés, transformés et exécutés. Une information ambiguë peut devenir une action plausible. Une instruction mal cadrée peut produire une sortie élégante et fausse.
La discipline de l’information devient donc plus importante, pas moins. Source, auteur, date, version, référentiel, unité, opposabilité, statut, confiance et limite d’usage doivent être explicités. Les métiers ne disparaissent pas dans l’IA ; ils doivent devenir plus exigeants sur les conditions du jugement.
Le conflit n’est pas humain contre IA. Il est contexte réel contre informatique figée.
Si cette hypothèse est juste, l’enjeu n’est pas de mettre une IA partout. L’enjeu est de produire une informatique enfin capable de servir les contextes réels, puis de se stabiliser quand le geste est mûr.
C’est peut-être en ce sens que l’ère de l’informatique commence réellement : non parce que les ordinateurs seraient nouveaux, mais parce que la société découvre que presque toute information peut devenir matière à raisonnement, traitement et vérification.