Le machine learning expliqué aux professionnels du bâtiment

Un exploitant de patrimoine reçoit chaque semaine des propositions qui promettent de prédire ses consommations, de détecter ses pannes avant qu’elles ne surviennent, d’optimiser ses installations et de réduire ses coûts, le tout grâce à l’intelligence artificielle. Il n’a généralement aucun moyen d’évaluer ces propositions. Non par manque de compétence — un ingénieur fluides comprend parfaitement une régression — mais parce que le vocabulaire employé est celui d’une autre discipline, et que les questions qui permettraient de trancher ne lui ont jamais été présentées.

Ce guide part de ce constat. Il ne s’adresse ni à des développeurs ni à des statisticiens, mais à des professionnels du bâtiment qui doivent comprendre le fonctionnement réel de ces méthodes : ce qu’elles apprennent, à partir de quelles données, ce qu’elles savent faire et ce qu’elles ne sauront jamais faire, comment on mesure honnêtement leur performance, et à quelles conditions leur résultat peut être utilisé pour engager une décision technique ou contractuelle.

L’angle retenu est délibérément sobre. Le machine learning est un outil statistique remarquable pour une classe précise de problèmes — ceux où l’on dispose de beaucoup d’exemples passés et où l’on cherche à reproduire une régularité — et il est inadapté, voire dangereux, en dehors de cette classe. Un bâtiment est un objet unique, soumis à des régimes changeants, dont l’instrumentation est souvent lacunaire et dont les comportements dépendent d’occupants imprévisibles. Ces caractéristiques ne rendent pas le machine learning inutile ; elles déterminent précisément où il est pertinent et comment il doit être encadré.

Ce qu’est réellement le machine learning, et ce qu’il n’est pas

En informatique classique, un professionnel décrit une règle et la machine l’applique. On écrit qu’au-delà de vingt-six degrés dans un local, la ventilation passe en grande vitesse ; la machine exécute cette instruction indéfiniment, exactement comme elle a été formulée. Le savoir est dans la règle, écrite par un humain, lisible, discutable et modifiable.

L’apprentissage automatique inverse cette logique. On ne fournit pas la règle mais des exemples : des milliers de situations passées décrites par des mesures, accompagnées du résultat observé. Un algorithme cherche alors, parmi une famille de fonctions mathématiques, celle qui reproduit le mieux la relation entre les mesures et le résultat. Le savoir n’est plus dans une règle écrite mais dans un ensemble de coefficients ajustés, que l’on appelle un modèle. Ce modèle peut ensuite produire une estimation pour une situation nouvelle.

Cette inversion a trois conséquences que tout professionnel du bâtiment doit intégrer avant d’aller plus loin. La première est que le modèle ne connaît que ce qui figure dans les exemples : il ne sait rien de la thermodynamique, rien de la réglementation, rien de l’histoire du bâtiment, sauf si ces éléments se traduisent dans les données qu’on lui a fournies. La deuxième est que le résultat n’est jamais une certitude mais une estimation assortie d’une incertitude, laquelle doit être exprimée pour que le résultat soit utilisable. La troisième est que la relation apprise n’est valable que dans le domaine couvert par les exemples : un modèle entraîné sur trois hivers doux se comportera de manière imprévisible lors d’un hiver rigoureux.

Le vocabulaire environnant mérite une clarification, car il est employé de manière interchangeable dans la communication commerciale alors qu’il désigne des réalités emboîtées. L’intelligence artificielle est le terme le plus large : il recouvre l’ensemble des techniques visant à faire accomplir par une machine des tâches associées à l’intelligence humaine, y compris des systèmes à base de règles qui ne comportent aucun apprentissage. Le machine learning, ou apprentissage automatique, en est un sous-ensemble : les techniques dont le comportement est dérivé de données plutôt que programmé. L’apprentissage profond est lui-même un sous-ensemble du machine learning, fondé sur des réseaux de neurones comportant de nombreuses couches ; il domine le traitement de l’image et du langage mais n’est pas la meilleure approche pour la plupart des données tabulaires du bâtiment. L’intelligence artificielle générative, enfin, désigne les modèles produisant du texte, de l’image ou du code, dont l’usage dans le bâtiment relève surtout de la rédaction, de la synthèse documentaire et de l’assistance, et non du calcul.

Ces distinctions ne relèvent pas du pédantisme. Elles sont normalisées : la norme ISO/IEC 22989, publiée en juillet 2022, fixe les concepts et la terminologie de l’intelligence artificielle, tandis que la norme ISO/IEC 23053, publiée en juin 2022, décrit spécifiquement le cadre des systèmes fondés sur l’apprentissage automatique. Toutes deux font l’objet d’amendements en cours d’élaboration, notamment pour couvrir l’intelligence artificielle générative ; ces travaux ne sont pas publiés et ne doivent donc pas être invoqués comme des exigences applicables.

Le vocabulaire minimal, en une page

Une variable explicative, souvent appelée caractéristique ou attribut, est une grandeur mesurée que l’on fournit au modèle : température extérieure, occupation, jour de la semaine, surface, année de construction. La variable cible est ce que l’on cherche à estimer : une consommation, une durée, une probabilité de panne, une catégorie.

L’entraînement est la phase pendant laquelle l’algorithme ajuste les coefficients du modèle sur des exemples dont le résultat est connu. L’inférence est l’utilisation du modèle entraîné sur une situation nouvelle. Le jeu d’entraînement sert à l’ajustement, le jeu de validation à régler les choix de configuration, et le jeu de test à mesurer la performance une seule et unique fois, sur des données que le modèle n’a jamais vues.

Le surapprentissage désigne un modèle qui a mémorisé le bruit de ses exemples au lieu d’en extraire la régularité : il est excellent sur son historique et médiocre sur toute donnée nouvelle. C’est le défaut le plus fréquent, et le plus facile à masquer.

Les trois familles d’apprentissage et ce qu’elles savent faire

Trois grandes familles de méthodes se distinguent par la nature des exemples fournis. Comprendre à quelle famille appartient une proposition suffit souvent à évaluer sa crédibilité.

L’apprentissage supervisé : apprendre à partir de réponses connues

C’est la famille la plus employée et la plus fiable. On fournit des exemples pour lesquels la réponse est connue : des historiques de consommation avec les conditions météorologiques correspondantes, des équipements avec leur date de défaillance, des projets terminés avec leur coût final. L’algorithme apprend la relation entre les variables explicatives et la réponse.

Deux cas se distinguent selon la nature de la réponse. Lorsqu’elle est une quantité continue — une consommation en kilowattheures, une durée en jours, un coût — on parle de régression. Lorsqu’elle est une catégorie — panne ou fonctionnement normal, conforme ou non conforme, type de défaut parmi une liste — on parle de classification. La distinction n’est pas cosmétique : elle détermine les indicateurs de performance à employer et la manière d’interpréter le résultat.

La condition d’usage est exigeante et souvent sous-estimée : il faut disposer d’exemples étiquetés, c’est-à-dire de situations passées dont la réponse est connue et documentée de manière fiable. Une organisation qui souhaite prédire les défaillances d’équipements mais dont la maintenance corrective n’a jamais été enregistrée avec précision ne dispose pas de ces étiquettes, et aucune technique ne peut compenser cette absence.

L’apprentissage non supervisé : chercher une structure sans réponse connue

Ici, aucune réponse n’est fournie. L’algorithme cherche une structure dans les données elles-mêmes. Deux usages dominent dans le bâtiment. Le regroupement rassemble des objets similaires : classer un parc de plusieurs centaines de bâtiments selon leurs profils de consommation réels plutôt que selon leur usage déclaré, par exemple, révèle souvent des familles inattendues et oriente utilement une stratégie de rénovation. La détection d’anomalies, quant à elle, identifie les observations qui s’écartent nettement du comportement habituel.

L’avantage de cette famille est de ne pas exiger d’étiquettes, ce qui la rend accessible à des organisations dont l’historique de maintenance est pauvre. Sa limite est symétrique : le résultat n’est pas une réponse mais une hypothèse. Un groupe identifié par un algorithme n’a pas de signification intrinsèque, et une anomalie détectée n’est pas nécessairement un défaut — ce peut être un usage exceptionnel parfaitement légitime, un changement d’occupation, ou un capteur défaillant. L’interprétation reste entièrement à la charge du professionnel.

L’apprentissage par renforcement : apprendre en agissant

Un agent prend des décisions successives dans un environnement et reçoit un signal de récompense qui traduit la qualité du résultat. Il apprend progressivement une politique d’action. Appliqué au bâtiment, cela signifierait par exemple apprendre une stratégie de pilotage de chauffage optimisant simultanément le confort et la consommation.

Cette famille est celle dont le potentiel est le plus discuté et l’usage réel le plus limité, pour une raison structurelle : l’apprentissage exige d’explorer, donc de prendre des décisions mauvaises pour découvrir qu’elles le sont. Sur un bâtiment occupé, cette exploration a un coût immédiat en inconfort, en consommation, voire en sécurité. Les mises en œuvre sérieuses passent donc par un apprentissage préalable sur un simulateur, ce qui reporte la difficulté sur la fidélité de ce simulateur, et par un encadrement strict des actions autorisées en exploitation réelle. Toute proposition d’apprentissage par renforcement directement sur un bâtiment occupé, sans bornes d’action explicites ni mécanisme de retour à un mode dégradé sûr, doit être considérée avec la plus grande réserve.

Anatomie d’un projet de machine learning appliqué au bâtiment

Un projet d’apprentissage automatique n’est pas un développement logiciel mais une démarche expérimentale. Sa structure est constante, et chaque étape omise produit une défaillance identifiable.

Tout commence par la formulation de la question métier, et c’est l’étape la plus déterminante. Une question mal posée conduit à un modèle techniquement irréprochable et opérationnellement inutile. Formuler correctement signifie répondre à quatre sous-questions. Quelle grandeur exactement doit être estimée, avec quelle unité et à quelle granularité temporelle ? À quel horizon — dans une heure, dans une semaine, à la fin du projet ? Quelle décision cette estimation va-t-elle éclairer, et qui la prendra ? Enfin, quelle erreur est acceptable, et quel est le coût d’une erreur dans chaque sens ? Cette dernière question est presque toujours escamotée, alors qu’elle détermine tout le reste : sous-estimer une consommation et la surestimer n’ont pas les mêmes conséquences, pas plus que manquer une panne ou déclencher une intervention inutile.

Vient ensuite la constitution du jeu de données. Il faut rassembler les historiques disponibles, les aligner sur une même base temporelle, traiter les valeurs manquantes, harmoniser les unités et vérifier la cohérence des horodatages. Cette phase représente en pratique la part dominante de l’effort d’un projet réel, et c’est une constante que les retours d’expérience confirment : dans l’analyse publiée à l’issue de la compétition internationale de prévision énergétique organisée par l’ASHRAE, le prétraitement des données est identifié comme le principal facteur de différenciation entre les équipes, davantage que le choix de l’algorithme.

L’ingénierie des variables consiste ensuite à construire, à partir des mesures brutes, des grandeurs qui portent l’information utile. C’est ici que la connaissance métier apporte sa contribution la plus décisive, et c’est la raison pour laquelle un projet confié à des data scientists sans ingénieur du bâtiment produit rarement de bons résultats. Un modèle de consommation devient nettement plus performant lorsqu’on lui fournit non pas la seule température extérieure instantanée mais des degrés-jours, des moyennes glissantes traduisant l’inertie thermique, un indicateur d’occupation, la position dans la semaine, les jours fériés et les périodes de vacances scolaires. Aucune de ces variables n’est présente dans les données brutes ; toutes proviennent d’une compréhension du fonctionnement physique et humain du bâtiment.

La séparation des données intervient avant tout entraînement, et son respect scrupuleux est la principale garantie d’honnêteté d’un projet. Une partie des données sert à entraîner, une autre à régler les choix de configuration, une troisième à mesurer la performance finale. Cette dernière ne doit être utilisée qu’une seule fois, à la toute fin. Pour des données temporelles, la séparation doit être chronologique et non aléatoire : entraîner sur des données de janvier et de mars pour tester sur février revient à demander au modèle d’interpoler dans un contexte qu’il connaît déjà, ce qui produit une performance flatteuse et trompeuse.

L’entraînement proprement dit est souvent l’étape la plus rapide, contrairement à ce que l’on imagine. Les bibliothèques disponibles rendent l’ajustement d’un modèle presque immédiat sur des volumes de données courants dans le bâtiment. L’évaluation qui suit demande en revanche du discernement, et elle fait l’objet d’une section entière plus loin.

Le déploiement transforme un modèle expérimental en service opérationnel. Il pose des questions concrètes que les démonstrations éludent : où le modèle s’exécute-t-il, à quelle fréquence, que se passe-t-il si une source de données est indisponible, comment le résultat est-il présenté à l’utilisateur, et selon quel mécanisme celui-ci peut-il le contester ou le corriger.

La surveillance et le réentraînement ferment la boucle, et constituent l’étape la plus négligée. Un modèle se dégrade parce que le monde change : le bâtiment est rénové, l’occupation évolue, un capteur dérive, une régulation est modifiée, un usage nouveau apparaît. Ce phénomène, appelé dérive, n’est pas un défaut du modèle mais une propriété de la situation. Il impose de surveiller en continu l’écart entre les prédictions et les observations, de définir un seuil au-delà duquel le modèle est suspendu, et de prévoir une procédure de réentraînement documentée. Un modèle mis en service sans dispositif de surveillance est un modèle dont personne ne saura dire, dans un an, s’il fonctionne encore.

Les données : le véritable chantier

Toutes les difficultés d’un projet d’apprentissage automatique dans le bâtiment se ramènent, en dernière analyse, à une question de données. Il est donc utile de connaître les sources disponibles, leurs défauts caractéristiques, et les pièges qui les accompagnent.

D’où viennent les données d’un bâtiment

La gestion technique du bâtiment constitue la source la plus riche et la plus difficile à exploiter. Elle produit des séries temporelles nombreuses — températures, débits, états de fonctionnement, consignes, alarmes — souvent enregistrées à des pas de temps hétérogènes, parfois seulement conservées quelques semaines, et dont le nommage des points suit une convention propre à l’installateur. Un travail de mise en correspondance des points avec les équipements réels est presque toujours nécessaire, et il représente une charge substantielle.

Les compteurs d’énergie et de fluides fournissent des séries plus propres et mieux structurées, mais leur granularité conditionne les usages possibles : une relève mensuelle permet un suivi de dérive, pas un diagnostic. Les capteurs additionnels — température, hygrométrie, dioxyde de carbone, présence — apportent l’information d’ambiance, avec une fiabilité très variable selon leur positionnement et leur entretien.

La maquette numérique et les référentiels de patrimoine apportent les caractéristiques statiques : surfaces, volumes, orientations, compositions de parois, types et puissances d’équipements, année de construction. Ces variables ne varient pas dans le temps mais expliquent une part importante des différences entre bâtiments d’un même parc. La structuration de ces données selon la série ISO 19650 et l’usage d’identifiants stables facilitent considérablement leur exploitation, car ils permettent de relier une série temporelle à l’objet physique qui la produit.

Les systèmes de gestion de maintenance contiennent les interventions, les pannes, les remplacements et les durées d’immobilisation. Ce sont les seules sources capables de fournir des étiquettes pour un apprentissage supervisé de défaillances. Leur qualité conditionne donc entièrement la faisabilité de ce type de projet, et elle est rarement à la hauteur : champs libres, catégories incohérentes, interventions non saisies, dates approximatives.

Les données météorologiques, enfin, sont indispensables à tout modèle énergétique et disponibles auprès de fournisseurs publics et privés. Le point de vigilance est la distance entre la station de référence et le bâtiment, qui peut introduire un écart significatif en milieu urbain.

Les défauts caractéristiques et leur traitement

Les valeurs manquantes sont universelles. Leur traitement dépend de leur cause, qu’il faut chercher à comprendre plutôt qu’à masquer. Une absence due à une coupure de communication n’a pas le même sens qu’une absence due à l’arrêt de l’équipement, laquelle porte au contraire une information. Remplacer mécaniquement toute valeur manquante par une moyenne détruit cette distinction et introduit un biais silencieux.

Les erreurs d’horodatage constituent le défaut le plus insidieux. Le passage à l’heure d’été, les fuseaux différents entre systèmes, les horloges dérivantes et les enregistrements décalés produisent des désalignements qui font apparaître des relations causales inversées. Un modèle apprenant qu’une consommation précède la commande qui la déclenche est un modèle dont les données sont désalignées, et le symptôme est facile à manquer.

Les capteurs défaillants produisent des valeurs plausibles mais fausses : une sonde bloquée sur une valeur constante, une dérive lente, une saturation. Ces défauts ne sont pas détectés par un contrôle de plage classique. Un examen visuel des séries, chronophage mais irremplaçable, reste la méthode la plus efficace pour les repérer avant qu’ils ne contaminent l’apprentissage.

L’hétérogénéité des unités et des conventions de signe est source d’erreurs d’ordre de grandeur. Une énergie exprimée tantôt en kilowattheures, tantôt en mégajoules, une puissance comptée positivement en soutirage sur un système et en injection sur un autre : ces incohérences doivent être vérifiées explicitement plutôt que supposées résolues.

Enfin, la question du volume est souvent mal posée. La quantité de données nécessaire ne se mesure pas en nombre de lignes mais en nombre de situations distinctes couvertes. Deux ans de données au pas horaire représentent des dizaines de milliers de lignes mais seulement deux hivers, deux étés, et un petit nombre d’épisodes climatiques extrêmes. Pour un modèle destiné à estimer une consommation en période de canicule, c’est deux exemples, pas dix-sept mille.

La fuite de données, l’erreur qui donne les meilleurs résultats

Une fuite de données survient lorsqu’une information qui ne sera pas disponible au moment de l’utilisation réelle se glisse dans les variables d’entraînement. Le modèle obtient alors une performance spectaculaire en apprentissage et s’effondre en exploitation.

Les formes les plus fréquentes dans le bâtiment sont faciles à décrire. Un modèle censé prévoir la consommation du lendemain auquel on fournit la température moyenne réelle du lendemain, alors qu’en exploitation on ne disposera que d’une prévision météorologique. Un modèle de détection de panne auquel on fournit un code d’alarme qui n’est émis qu’après la panne. Une normalisation des données calculée sur l’ensemble du jeu avant la séparation, ce qui transmet au jeu d’entraînement une information issue du jeu de test.

La règle de vérification est simple et devrait être posée systématiquement au fournisseur d’un modèle : chacune des variables d’entrée sera-t-elle réellement disponible, avec cette valeur, au moment où la prédiction devra être produite ? Une performance annoncée qui semble trop belle s’explique presque toujours par une fuite plutôt que par un talent particulier.

Évaluer un modèle sans se tromper soi-même

L’évaluation est la partie du sujet où un professionnel du bâtiment peut le plus rapidement acquérir une compétence décisive. Elle ne demande aucune connaissance en programmation, seulement de la rigueur et quelques notions.

Mesurer une erreur de prédiction quantitative

Lorsque le modèle estime une quantité, plusieurs indicateurs coexistent et ne disent pas la même chose. L’erreur absolue moyenne est la moyenne des écarts en valeur absolue entre prédiction et réalité : elle s’exprime dans l’unité de la grandeur estimée, ce qui la rend immédiatement interprétable. La racine de l’erreur quadratique moyenne pénalise davantage les grands écarts, ce qui la rend préférable lorsqu’une erreur importante est disproportionnellement coûteuse. L’erreur relative moyenne exprime l’écart en pourcentage, ce qui facilite la comparaison entre bâtiments de tailles différentes mais devient instable lorsque les valeurs réelles sont proches de zéro.

Le domaine énergétique dispose d’indicateurs consacrés et d’un cadre normatif, ce qui constitue un avantage considérable par rapport à d’autres applications. Le coefficient de variation de la racine de l’erreur quadratique moyenne et le biais normalisé sont les deux grandeurs employées pour juger de la qualité d’un modèle de référence énergétique. Le premier mesure la dispersion des erreurs rapportée à la moyenne des consommations, le second mesure si le modèle surestime ou sous-estime systématiquement — un modèle peut avoir une dispersion acceptable tout en présentant un biais systématique, ce qui le rend impropre à quantifier une économie.

Ces indicateurs et leurs seuils d’acceptation sont définis dans le guide ASHRAE Guideline 14, consacré à la mesure des économies d’énergie, de puissance et d’eau, dont l’édition 2023 a fait l’objet d’un addendum publié en octobre 2025. Les seuils dépendent de la granularité des données, mensuelle ou horaire, et il convient de se reporter à l’édition applicable plutôt que de reprendre des valeurs mémorisées. Le protocole international de mesure et de vérification de la performance énergétique, dont l’édition des concepts fondamentaux publiée par l’Efficiency Valuation Organization fait référence, fournit le cadre méthodologique correspondant. Ce point mérite d’être souligné : lorsqu’un modèle prédictif sert à quantifier une économie contractuelle, il ne suffit pas qu’il soit bon au sens statistique, il doit satisfaire des critères d’acceptation reconnus.

Mesurer une erreur de classification

Lorsque le modèle attribue une catégorie, le taux de bonnes réponses est l’indicateur le plus intuitif et le plus trompeur. Sur un parc où les équipements tombent rarement en panne, un modèle qui prédit systématiquement l’absence de panne obtiendra un taux de bonnes réponses excellent tout en étant parfaitement inutile. Ce piège, appelé déséquilibre des classes, est la règle plutôt que l’exception dans le bâtiment, où les événements intéressants sont par nature rares.

Deux indicateurs complémentaires s’imposent donc. La précision répond à la question : parmi les cas signalés par le modèle, quelle proportion en était réellement ? Elle mesure le coût des fausses alertes. Le rappel répond à la question inverse : parmi les cas réellement survenus, quelle proportion le modèle a-t-il signalés ? Il mesure le coût des cas manqués. Ces deux grandeurs varient en sens inverse : rendre un modèle plus sensible augmente le rappel et dégrade la précision.

Le choix du compromis entre les deux n’est pas technique mais économique, et il appartient au professionnel, pas au prestataire. Pour une panne de groupe froid en période estivale sur un site sensible, manquer un cas coûte infiniment plus cher qu’une intervention préventive inutile : on privilégiera le rappel. Pour un système qui déclencherait un déplacement d’équipe sur un site distant, une fausse alerte coûte cher et détruit la confiance des équipes : on privilégiera la précision. Aucun modèle ne peut trancher cet arbitrage, et un fournisseur qui présente un unique chiffre de performance sans discuter ce compromis n’a pas compris le problème.

La comparaison de référence, souvent oubliée

Aucune performance n’a de sens dans l’absolu. Elle ne prend sens que comparée à une référence simple. Avant d’évaluer un modèle sophistiqué, il faut mesurer la performance d’une méthode élémentaire sur les mêmes données : prédire que la consommation de demain sera celle du même jour la semaine précédente, ou une moyenne conditionnée à la température extérieure et au type de jour. Cette référence est souvent étonnamment bonne.

La question à poser devient alors précise et redoutablement efficace : de combien le modèle proposé fait-il mieux que cette référence, et cet écart justifie-t-il son coût de mise en œuvre et de maintenance ? Beaucoup de projets ne survivent pas à cette question, et c’est une bonne nouvelle : ils auraient consommé des ressources pour un gain marginal sur une méthode que l’équipe aurait pu maintenir elle-même.

La validation croisée complète ce dispositif en évaluant le modèle sur plusieurs découpages successifs des données plutôt que sur un seul, ce qui donne une idée de la stabilité de sa performance. Sur des données temporelles, elle doit respecter l’ordre chronologique, en entraînant toujours sur le passé pour évaluer sur le futur — la documentation de référence des bibliothèques d’apprentissage courantes décrit précisément ces variantes, notamment dans la documentation de scikit-learn consacrée à la validation croisée.

Les cas d’usage réellement matures dans le bâtiment

Il est plus utile de classer les applications par degré de maturité réelle que par ordre d’enthousiasme. Les six familles suivantes couvrent l’essentiel de ce qui fonctionne aujourd’hui en exploitation.

La prévision de consommation et la mesure des économies

C’est l’application la mieux établie, pour trois raisons convergentes : les données existent, la grandeur cible est mesurée directement, et un cadre méthodologique d’acceptation existe. Un modèle apprend la relation entre la consommation et ses déterminants — conditions climatiques, calendrier, occupation, éventuellement production interne — puis estime ce qu’aurait été la consommation en l’absence d’intervention. La différence avec la consommation observée constitue l’économie mesurée.

Le niveau de performance atteignable et ses limites ont été documentés à grande échelle. La compétition internationale de prévision de consommation organisée par l’ASHRAE, dont les résultats ont été publiés dans la revue Science and Technology for the Built Environment en 2020, portait sur un jeu de données réel de 1 448 bâtiments et 2 380 compteurs provenant de 16 sources, avec plus de vingt millions de points d’entraînement. Elle a rassemblé 4 370 participants répartis en 3 614 équipes issues de 94 pays. Deux enseignements en ressortent, et ils sont plus instructifs que n’importe quelle démonstration commerciale : les solutions les plus performantes reposaient sur de grands ensembles de modèles d’arbres à gradient renforcé plutôt que sur des réseaux de neurones profonds, et le prétraitement des données s’est révélé le principal facteur de différenciation entre les équipes.

Une analyse ultérieure des erreurs de cette même compétition, publiée dans la même revue en 2022 et disponible en accès libre sous la référence arXiv 2106.13475, examine précisément où les meilleurs modèles échouent. Ce type de travail est infiniment plus utile à un professionnel qu’une annonce de performance moyenne, car il décrit les conditions dans lesquelles la prédiction se dégrade.

La détection d’anomalies et le diagnostic de défauts

Cette famille consiste à identifier les comportements s’écartant du fonctionnement attendu : une consommation nocturne anormale, un groupe qui fonctionne en même temps qu’un autre alors qu’ils devraient alterner, une température de départ qui ne suit plus sa consigne, un débit incompatible avec la position d’un registre.

Deux approches coexistent. La première, non supervisée, ne demande aucun historique de pannes : elle apprend le comportement habituel et signale les écarts. Elle est immédiatement applicable et produit beaucoup de signalements, dont une partie importante correspond à des situations légitimes. La seconde, supervisée, classe les défauts par type mais exige un historique étiqueté que peu d’organisations possèdent réellement.

La distinction décisive, et elle est la même que dans tous les domaines de l’automatisation technique, sépare la détection du diagnostic. Un algorithme signale un écart ; il n’en désigne pas la cause. Un écart de température de départ peut provenir d’un défaut de production, d’un problème hydraulique, d’une régulation mal paramétrée, d’une sonde défaillante ou d’un changement d’usage. Les systèmes qui prétendent produire directement un diagnostic reposent en réalité, dans leur partie utile, sur des règles expertes écrites par des ingénieurs — ce qui est parfaitement légitime, mais relève du système à base de règles et non de l’apprentissage.

La maintenance prédictive

L’ambition est d’estimer la probabilité de défaillance d’un équipement à un horizon donné, afin d’intervenir avant la panne sans remplacer prématurément. C’est le cas d’usage le plus demandé et l’un des plus difficiles, pour une raison simple : les pannes sont rares. Un équipement qui tombe en panne tous les cinq ans fournit très peu d’exemples positifs, et un modèle a besoin d’exemples pour apprendre.

Les mises en œuvre qui réussissent contournent cette difficulté de deux manières. Elles s’appuient d’abord sur des flottes : mille équipements identiques sur un patrimoine produisent bien plus d’exemples qu’un équipement unique. Elles se rabattent ensuite souvent sur un objectif plus modeste et plus atteignable — détecter une dégradation de performance plutôt que prédire une date de panne. Estimer qu’une pompe consomme progressivement davantage pour le même service est un résultat exploitable, obtenu sans avoir à prédire l’imprévisible.

Le pilotage et l’optimisation du confort

L’apprentissage peut contribuer au pilotage de deux manières bien distinctes. La première, mature, consiste à prédire une grandeur qui alimente ensuite une régulation classique : anticiper le besoin de relance en fonction de la température prévue et de l’inertie observée du bâtiment, par exemple. Le modèle prédit, la logique de commande reste déterministe et vérifiable.

La seconde consiste à laisser un système apprendre directement une politique de commande. Elle relève de l’apprentissage par renforcement et de ses réserves déjà énoncées. Dans tous les cas, un principe doit être posé sans exception : toute commande issue d’un modèle probabiliste doit être bornée par des sécurités déterministes non contournables — plages de consigne, limites de température, verrouillages de sécurité, retour automatique à un mode dégradé sûr en cas d’indisponibilité du modèle. Ces sécurités ne sont pas une précaution de principe : elles sont la condition pour que la responsabilité de l’exploitant reste tenable.

L’estimation de coûts et de durées

Estimer le coût ou la durée d’une opération à partir de projets passés est une application séduisante et exigeante. Elle suppose un historique de projets décrits de manière homogène, avec leurs caractéristiques et leur résultat final, ce qui implique une discipline de capitalisation que peu d’organisations maintiennent.

La difficulté supplémentaire tient à l’hétérogénéité : deux opérations de même surface et de même usage peuvent différer d’un facteur important selon la complexité du site, les contraintes réglementaires locales, la conjoncture du marché ou la qualité des entreprises. Un modèle statistique reproduit la moyenne de ce qui a été observé ; il ne capture pas ce qui fait la singularité d’une opération. Il constitue donc un outil de premier cadrage et de détection d’écarts par rapport aux ordres de grandeur habituels, pas un outil d’engagement.

La vision par ordinateur et l’extraction documentaire

L’analyse automatique d’images de chantier permet aujourd’hui de repérer des situations de sécurité, de suivre un avancement, de compter des éléments. Les performances sont réelles et les limites connues : elles dépendent fortement des conditions de prise de vue, elles se dégradent sur des configurations peu représentées dans les données d’entraînement, et elles produisent des faux positifs comme des faux négatifs. Un usage responsable consiste à alimenter une revue humaine plutôt qu’à produire un constat automatique, en particulier lorsque le sujet est la sécurité des personnes.

L’extraction d’information depuis des documents — pièces écrites, notices, rapports de contrôle, plans — relève d’une autre famille technique mais répond au même principe : le résultat est une proposition à vérifier. Elle est particulièrement utile pour structurer un fonds documentaire ancien, à condition d’accepter un taux d’erreur et d’organiser la vérification des données critiques.

Ce que le machine learning ne saura pas faire

Un guide honnête consacre autant d’attention aux limites qu’aux possibilités, d’autant que ces limites sont structurelles et non conjoncturelles : elles ne seront pas levées par la prochaine génération d’algorithmes.

La première est l’incapacité à établir une causalité. Un modèle apprend des associations. S’il observe que la consommation augmente lorsqu’un certain ventilateur fonctionne, il ne peut pas distinguer entre trois situations : le ventilateur cause la consommation, une troisième variable cause les deux, ou la relation est fortuite. Cette distinction est vitale dès que l’on veut agir, car une action fondée sur une corrélation non causale ne produit pas l’effet attendu. Établir une causalité exige soit une expérimentation contrôlée, soit une modélisation physique, soit des méthodes d’inférence causale spécifiques — jamais un simple apprentissage sur des données d’observation.

La deuxième est l’extrapolation. Un modèle interpole correctement à l’intérieur du domaine couvert par ses exemples et devient imprévisible au-delà. Un modèle de consommation entraîné sur des températures comprises entre moins cinq et trente-deux degrés ne produira pas une erreur explicite à trente-huit degrés : il produira une valeur, calculée par prolongement mathématique, sans aucune garantie. Or c’est précisément dans ces conditions extrêmes que les décisions importent le plus. Un modèle destiné à un usage opérationnel devrait donc systématiquement signaler lorsqu’il est sollicité hors de son domaine d’apprentissage, et cette fonctionnalité devrait être exigée explicitement.

La troisième est la sensibilité aux changements de régime. Un bâtiment rénové, une occupation modifiée, un changement d’horaires, une nouvelle régulation, un usage inédit : à chaque fois, la relation apprise devient partiellement obsolète. Le modèle continue pourtant de produire des valeurs avec le même aplomb. Ce n’est pas un défaut de conception mais la conséquence directe de son principe de fonctionnement, et c’est la raison pour laquelle la surveillance de la dérive n’est pas une option.

La quatrième tient à la rareté des données dans beaucoup de situations intéressantes. Le bâtiment produit énormément de données répétitives et très peu de données sur les événements qui comptent : les pannes graves, les épisodes climatiques extrêmes, les incidents de sécurité. Or l’apprentissage automatique est efficace là où les exemples abondent, c’est-à-dire précisément là où les enjeux sont les plus faibles.

La cinquième est l’unicité de chaque bâtiment. Un modèle entraîné sur un ouvrage ne se transpose pas directement à un autre, car les caractéristiques constructives, les équipements, les usages et le climat diffèrent. Des approches existent pour transférer partiellement un apprentissage d’un bâtiment à un autre, mais elles supposent une similarité qu’il faut démontrer plutôt que postuler. Une offre présentant un modèle universel applicable à tout patrimoine mérite une question directe sur les bâtiments ayant servi à son entraînement.

La sixième, enfin, est l’ignorance de la physique. Un modèle purement statistique peut produire une prédiction qui viole la conservation de l’énergie, une contrainte d’équilibre ou une limite d’équipement, tout simplement parce que rien ne l’en empêche. Des contrôles de vraisemblance physique doivent donc être placés en aval de tout modèle destiné à un usage opérationnel — une prédiction qui dépasse la puissance installée doit être rejetée, pas transmise.

Modèles physiques et modèles statistiques : opposition ou complémentarité

Le débat entre simulation physique et apprentissage statistique est souvent présenté comme un affrontement. Il est plus fécond de le poser comme un choix de positionnement sur un continuum, chaque option ayant un domaine de pertinence propre.

Un modèle de type boîte blanche repose entièrement sur les équations physiques : transferts thermiques, mécanique des fluides, thermodynamique des équipements. Ses paramètres sont des grandeurs physiques interprétables. Il possède deux avantages décisifs : il fonctionne sans historique, ce qui le rend indispensable en conception, et il reste valide hors du domaine observé puisqu’il ne dépend d’aucun échantillon. Ses faiblesses sont le coût de construction, la difficulté de caler ses paramètres sur le comportement réel, et un écart souvent important avec les consommations mesurées.

Un modèle de type boîte noire repose entièrement sur les données. Il est rapide à construire dès lors qu’un historique existe, il capture les comportements réels y compris ceux qu’aucune équation ne décrit — les habitudes des occupants, par exemple — et il atteint généralement une meilleure précision sur le domaine observé. Ses faiblesses sont la dépendance à l’historique, l’absence de sens physique de ses paramètres et l’invalidité hors domaine.

Entre les deux, les modèles de type boîte grise combinent une structure physique simplifiée dont certains paramètres sont ajustés sur les mesures. Cette approche est souvent la plus adaptée au bâtiment en exploitation : elle conserve une interprétabilité — les paramètres ajustés correspondent à des grandeurs physiques que l’on peut discuter et confronter au bon sens de l’ingénieur — tout en s’adaptant au comportement réel. Elle demande moins de données qu’une approche purement statistique, ce qui compte lorsque l’historique est court.

La calibration d’un modèle de simulation sur des mesures constitue un cas particulier de cette hybridation, et elle bénéficie du même encadrement méthodologique que la mesure des économies : les indicateurs et critères d’acceptation du guide ASHRAE consacré à la mesure des économies servent également à qualifier un modèle calibré. Une autre combinaison consiste à conserver un modèle physique comme référence et à faire apprendre par un modèle statistique l’écart entre cette référence et la mesure. Le résidu ainsi appris capture ce que la physique simplifiée ne décrit pas, tout en conservant un comportement raisonnable hors du domaine observé.

La règle de choix se résume simplement. Sans historique, en conception ou pour évaluer une situation qui n’a jamais existé, la modélisation physique est la seule option. Avec un historique substantiel et une question portant sur un comportement dans des conditions comparables à celles observées, l’approche statistique est plus rapide et plus précise. Dans la majorité des situations d’exploitation, une combinaison des deux surpasse chacune prise isolément.

Faire ou acheter : outils, prestataires et questions à poser

Une organisation du bâtiment n’a pas vocation à devenir un laboratoire d’apprentissage automatique. La question pratique est donc de savoir ce qu’elle internalise et ce qu’elle confie, et surtout comment elle évalue ce qu’elle achète.

Du côté des outils, le paysage est plus stable et plus accessible qu’on ne le croit. Pour les données tabulaires et les séries temporelles qui constituent l’essentiel des applications du bâtiment, les bibliothèques classiques d’apprentissage — dont la documentation de scikit-learn constitue une référence pédagogique de premier ordre — couvrent la quasi-totalité des besoins. Les méthodes d’arbres à gradient renforcé y occupent une place particulière : elles sont robustes, tolèrent des données imparfaites, demandent peu de réglages et dominent régulièrement les comparaisons sur ce type de données, comme l’a confirmé la compétition ASHRAE évoquée plus haut. L’apprentissage profond, plus exigeant en données et en compétences, se justifie pour l’image, le langage et certaines séries complexes, rarement pour un suivi énergétique.

L’enjeu réel n’est pas l’algorithme mais l’industrialisation : la collecte fiable des données, l’exécution périodique, la surveillance, le versionnement des modèles et des jeux de données, la traçabilité des prédictions. C’est là que se situent la vraie difficulté et le vrai coût, et c’est ce qu’une organisation doit examiner en priorité lorsqu’elle évalue une offre.

Sept questions permettent de distinguer une proposition sérieuse d’une proposition creuse, et elles ne demandent aucune compétence technique pour être posées. Sur quelles données précises le modèle a-t-il été entraîné, et ces données proviennent-elles de bâtiments comparables aux miens ? Quelle est la performance mesurée sur un jeu de test indépendant, et quelle est celle d’une méthode de référence simple sur les mêmes données ? Chaque variable d’entrée sera-t-elle réellement disponible au moment où la prédiction devra être produite ? Que fait le système lorsqu’il est sollicité hors de son domaine d’apprentissage — le signale-t-il ou produit-il une valeur silencieusement ? Comment la dérive est-elle surveillée, selon quel indicateur et quel seuil, et qui est alerté ? Qui est propriétaire des données transmises, où sont-elles hébergées, et peuvent-elles servir à entraîner des modèles vendus à des tiers ? Enfin, que se passe-t-il en fin de contrat : le modèle, les données et les résultats restent-ils exploitables par l’organisation ?

Un fournisseur solide répond à ces sept questions sans détour et souvent avec soulagement, parce qu’elles lui permettent de montrer un travail que les appels d’offres ignorent habituellement. Un fournisseur qui les esquive au profit d’une démonstration visuelle apporte une réponse suffisante en soi.

La performance annoncée n’est pas une performance mesurée

Un chiffre de performance n’a de sens que s’il est accompagné de quatre précisions : sur quelles données il a été obtenu, comment ces données ont été séparées de celles de l’entraînement, à quelle méthode de référence il se compare, et sur quelle période il a été observé en exploitation réelle.

Une précision annoncée à quatre-vingt-quinze pour cent sans ces précisions peut recouvrir un modèle excellent comme un modèle qui prédit systématiquement la classe majoritaire sur un jeu déséquilibré. Les deux affichent le même chiffre, et seul le contexte permet de les distinguer.

Demander ces quatre précisions n’est pas de la défiance : c’est l’équivalent, pour un modèle, de demander le procès-verbal d’essai d’un équipement plutôt que sa plaquette commerciale.

Gouvernance, conformité et responsabilité

Introduire un système apprenant dans l’exploitation d’un bâtiment soulève des questions de responsabilité que le secteur commence seulement à formaliser. Elles se regroupent en quatre domaines.

Le premier concerne la responsabilité technique. Lorsqu’une commande issue d’un modèle produit un dommage — un dégât par gel, une rupture de confort dans un établissement sensible, une surconsommation importante — la question de savoir qui répond se pose dans des termes que le droit de la construction n’a pas anticipés. La réponse pratique consiste à ne jamais placer un modèle probabiliste en position de décision non bornée : les sécurités déterministes, les plages autorisées et les modes dégradés doivent être conçus par des ingénieurs et rester indépendants du modèle. Ce n’est pas une précaution excessive, c’est ce qui rend la chaîne de responsabilité intelligible.

Le deuxième concerne les données à caractère personnel. Les données d’occupation, de présence, de badgeage, d’usage individuel des locaux, et a fortiori les images de vidéosurveillance, relèvent d’un régime juridique exigeant. Un projet qui ambitionne de prédire l’occupation ou d’optimiser des espaces à partir de données de présence doit intégrer dès sa conception les principes de minimisation, d’agrégation et de finalité, ainsi que l’information des personnes concernées. L’agrégation à une maille suffisamment large résout la plupart des situations sans dégrader l’utilité opérationnelle.

Le troisième concerne la confidentialité industrielle et la sécurité. Les données d’exploitation d’un patrimoine décrivent ses vulnérabilités : horaires réels d’occupation, équipements critiques, périodes de faible surveillance, points faibles techniques. Leur transmission à un prestataire externe doit être encadrée contractuellement, avec des clauses explicites sur l’hébergement, la durée de conservation, la réutilisation pour l’entraînement de modèles destinés à des tiers, et la restitution en fin de contrat.

Le quatrième concerne le cadre normatif et réglementaire, qui s’est considérablement structuré. La norme ISO/IEC 42001, publiée en décembre 2023, définit les exigences d’un système de management de l’intelligence artificielle et constitue la référence organisationnelle pour une structure souhaitant encadrer ses usages de manière certifiable. La norme ISO/IEC 23894, publiée en février 2023, fournit des lignes directrices spécifiques sur la gestion des risques liés à l’intelligence artificielle. Le cadre de gestion des risques du NIST, diffusé en janvier 2023 dans sa version 1.0 et organisé autour des quatre fonctions Govern, Map, Measure et Manage, offre une structure volontaire utile pour organiser la réflexion sans formalisme excessif ; il a été complété en juillet 2024 par un profil consacré à l’intelligence artificielle générative et fait l’objet de travaux de révision.

Pour les organisations opérant dans l’Union européenne s’ajoute un cadre contraignant. Le règlement européen sur l’intelligence artificielle est entré en vigueur le 1er août 2024 et s’applique de façon échelonnée : interdictions et dispositions générales depuis février 2025, obligations relatives aux modèles à usage général depuis août 2025, entrée en application de la majorité des règles en août 2026, tandis que le calendrier officiel situe l’application des règles relatives aux systèmes à haut risque de l’annexe III en décembre 2027 et celles concernant les systèmes intégrés à des produits réglementés en août 2028. Ce calendrier a fait l’objet d’ajustements législatifs récents et continue d’évoluer ; la qualification d’un usage donné doit être vérifiée auprès des sources officielles plutôt que déduite d’une synthèse, y compris celle-ci. La plupart des applications décrites dans ce guide — prévision de consommation, détection d’anomalies techniques, maintenance — ne relèvent pas a priori des catégories les plus contraignantes, mais cette appréciation dépend de l’usage concret et non de la technologie employée.

Un dernier point mérite d’être posé, car il conditionne l’acceptation par les équipes. Un système qui produit des signalements sans expliquer sur quoi ils reposent est abandonné en quelques mois, quelle que soit sa performance statistique. Fournir, avec chaque prédiction, les principales variables qui l’ont déterminée et une indication d’incertitude n’est pas un raffinement : c’est ce qui permet à un technicien d’exercer son jugement plutôt que de subir un verdict, et c’est donc ce qui rend le dispositif utilisable.

Mesurer la valeur d’un projet d’apprentissage automatique

Le retour sur investissement de ces projets est souvent affirmé et rarement démontré, pour une raison structurelle : la valeur réside fréquemment dans des incidents évités, donc non observés. Il reste possible de l’établir honnêtement, à condition de définir les grandeurs avant le déploiement.

Quatre postes de gain se mesurent réellement. Les économies d’énergie attribuables à une action, à condition qu’elles soient quantifiées selon une méthode reconnue de mesure et vérification plutôt que par simple comparaison de factures — c’est précisément l’objet des référentiels évoqués plus haut. Le temps d’analyse économisé par les équipes techniques, lorsque le système hiérarchise les situations à examiner au lieu de laisser un technicien parcourir des courbes. Les interventions curatives évitées grâce à une détection précoce, à condition d’en tenir un journal daté avec une estimation de coût établie à froid. Et la réduction des interventions inutiles, lorsque le système écarte des alarmes qui déclenchaient auparavant des déplacements.

Du côté des coûts, il faut compter la mise en qualité et l’instrumentation des données, qui constitue le poste le plus lourd et le plus systématiquement sous-estimé ; le développement ou l’abonnement ; l’intégration aux systèmes existants ; la formation des équipes et l’accompagnement du changement ; et surtout la maintenance du dispositif dans la durée, qui inclut la surveillance, le réentraînement et la reprise à chaque modification du bâtiment ou de son instrumentation.

La formule de base se lit comme la différence entre les gains et les coûts récurrents :

Gain net annuel = [ Économies d’énergie vérifiées ] + [ Temps d’analyse économisé × Coût horaire ] + [ Coût des interventions évitées ] − [ Coût de maintenance et de surveillance annuel ]

Voici un exemple pédagogique entièrement fictif, destiné à illustrer la mécanique du calcul. Les valeurs sont arbitraires et ne représentent aucune moyenne sectorielle. Supposons un patrimoine de vingt bâtiments tertiaires dont la facture énergétique annuelle fictive s’élève à 900 000 unités monétaires. Supposons qu’un dispositif de détection d’anomalies permette d’identifier et de corriger des dérives représentant une économie vérifiée de 2 % de cette facture, soit 18 000 unités. Supposons par ailleurs que la hiérarchisation automatique des situations à examiner libère fictivement 250 heures d’analyse par an, au coût horaire interne fictif de 60 unités, soit 15 000 unités. Ajoutons trois interventions curatives évitées dont le coût fictif serait de 4 000 unités chacune, soit 12 000 unités. Le gain brut atteindrait 45 000 unités.

En retranchant un coût annuel fictif de 22 000 unités couvrant l’abonnement, la surveillance et le réentraînement, le gain net s’établirait à 23 000 unités. Pour un investissement initial fictif de 60 000 unités couvrant la mise en qualité des données, l’intégration et la formation, le délai de retour serait d’environ deux ans et demi.

Cet exemple appelle des réserves substantielles, et les énoncer fait partie de l’honnêteté d’un tel calcul. Le poste des interventions évitées repose sur un jugement d’expert, puisqu’on ne peut pas observer un incident qui n’a pas eu lieu ; la méthode la plus rigoureuse consiste à documenter chaque détection avec une estimation contradictoire de ce qu’elle a évité, en assumant qu’il s’agit d’une hypothèse. L’économie d’énergie n’est attribuable au dispositif que si la méthode de vérification neutralise correctement les effets climatiques et d’occupation, faute de quoi on mesure un hiver doux plutôt qu’une performance. Le temps libéré ne constitue une économie que s’il est effectivement réaffecté. Enfin, le calcul ignore un bénéfice réel mais difficile à monétiser : la connaissance fine du fonctionnement de son patrimoine qu’une organisation acquiert en construisant ce dispositif, et qui produit souvent plus de valeur que le modèle lui-même.

Déployer un premier projet sur quatre-vingt-dix jours

Trois mois suffisent pour obtenir un résultat évaluable, à condition de choisir un périmètre étroit et de consacrer la majorité du temps aux données plutôt qu’aux algorithmes.

Phase un : cadrage de la question et inventaire des données

Les trois premières semaines ne produisent aucun modèle. Elles servent à formuler précisément la question métier selon les quatre sous-questions énoncées plus haut — quelle grandeur, à quel horizon, pour quelle décision, avec quelle erreur acceptable — et à inventorier ce qui existe réellement. Cet inventaire réserve presque toujours des surprises : historiques plus courts qu’annoncé, points de mesure non documentés, exports impossibles à automatiser, interventions de maintenance non saisies.

Cette phase établit aussi la situation de référence : combien de temps consacrent aujourd’hui les équipes à la tâche visée, et quelle est la performance de la méthode actuelle, même informelle. Sans cette mesure préalable, aucune évaluation ultérieure ne sera crédible. Le critère de sortie est un document court validé par l’exploitant, décrivant la question, les données disponibles, la référence et le critère de succès chiffré.

Phase deux : préparation des données et méthode de référence

Les semaines quatre à sept sont consacrées à l’extraction, à l’alignement temporel, au traitement des valeurs manquantes, à la vérification des unités et des horodatages, et à l’examen visuel des séries pour repérer les capteurs défaillants. C’est la phase la plus longue et la moins spectaculaire, et vouloir l’abréger est la décision la plus coûteuse d’un projet.

Elle se conclut par la mise en place d’une méthode de référence simple et de son évaluation. Disposer de ce point de comparaison avant tout modèle sophistiqué change la nature de la discussion ultérieure, car toute performance sera désormais rapportée à un repère. Il n’est pas rare que cette étape suffise à répondre au besoin, et c’est un résultat, pas un échec.

Phase trois : modélisation et évaluation

Les semaines huit à dix construisent un ou deux modèles, avec une séparation stricte des jeux de données et une séparation chronologique pour les séries temporelles. L’évaluation porte sur les indicateurs choisis à la phase un, comparés à la référence, avec un examen explicite des cas où le modèle échoue — pas seulement de sa performance moyenne.

Le principe directeur est de rester délibérément simple. Un modèle compréhensible atteignant quatre-vingt-dix pour cent de la performance d’un modèle complexe est presque toujours préférable en exploitation, parce qu’il sera maintenu, expliqué et accepté. Cette phase produit également la maquette de restitution : la manière dont le résultat sera présenté aux équipes conditionne son adoption au moins autant que sa justesse.

Phase quatre : mise en service encadrée et surveillance

Les semaines onze à treize déploient le modèle en fonctionnement parallèle : il produit ses résultats sans qu’aucune décision ne repose sur lui, pendant que les équipes continuent leur méthode habituelle. On compare, on documente les écarts, on ajuste les seuils de signalement en fonction du volume d’alertes réellement soutenable par l’équipe — un dispositif qui produit trente signalements par jour pour deux techniciens sera ignoré, quelle que soit sa pertinence statistique.

La phase se conclut par la mise en gouvernance : désignation d’un propriétaire, définition des indicateurs de surveillance de la dérive et de leurs seuils, procédure documentée de réentraînement, conservation des versions du modèle et des jeux de données, et décision explicite sur l’extension à d’autres bâtiments.

Qui fait quoi

L’exploitant ou le responsable technique est propriétaire de la question métier et du critère de succès ; il valide que le résultat correspond à un besoin réel et arbitre le compromis entre fausses alertes et cas manqués. L’ingénieur du bâtiment apporte la connaissance physique qui guide la construction des variables et détecte les résultats absurdes qu’aucune statistique ne signalera. Le spécialiste des données construit, évalue et industrialise le modèle ; il ne décide ni de la question ni des seuils. Le responsable des systèmes d’information garantit l’accès aux données, l’hébergement et la sécurité. Les techniciens d’exploitation, enfin, sont les utilisateurs finaux : leur retour sur la pertinence des signalements est la principale source d’amélioration, et leur désengagement est le signal d’alerte le plus fiable.

Cinq niveaux de maturité en exploitation des données du bâtiment

Se situer permet d’éviter deux erreurs opposées : engager un projet d’apprentissage sur un socle de données inexistant, ou renoncer à des méthodes accessibles au prétexte qu’elles paraissent sophistiquées.

Au premier niveau, les données existent mais ne sont pas accessibles. Les historiques de gestion technique sont écrasés après quelques semaines, les exports se font manuellement à la demande, les points de mesure ne sont pas documentés et personne ne sait exactement ce que mesure telle sonde. Aucun projet d’apprentissage n’est possible, et il serait irresponsable d’en lancer un. La condition pour progresser n’est pas technique mais budgétaire et contractuelle : obtenir l’archivage durable des données et leur accès automatisé, ce qui se négocie avec l’exploitant et l’intégrateur.

Au deuxième niveau, les données sont archivées et accessibles, mais leur signification n’est pas formalisée. On dispose de milliers de séries dont le nommage suit une convention d’installateur. Un travail de mise en correspondance des points avec les équipements réels et de documentation des unités est nécessaire. Ce travail, ingrat, constitue l’investissement le plus rentable de toute la démarche, car il conditionne tout ce qui suit. Le risque à ce stade est de croire qu’un prestataire d’intelligence artificielle le fera à votre place : il le facturera, sans posséder la connaissance du site nécessaire pour le faire correctement.

Au troisième niveau, les données sont accessibles et documentées, et l’organisation les exploite par des méthodes descriptives : tableaux de bord, comparaisons, signatures énergétiques, suivi de dérive par régression simple. Une part importante de la valeur souvent attribuée à l’intelligence artificielle s’obtient en réalité à ce niveau, à moindre coût et avec une transparence totale. La condition pour progresser est d’identifier un besoin précis auquel ces méthodes ne répondent pas.

Au quatrième niveau, des modèles prédictifs sont en service sur un périmètre défini, avec une évaluation rigoureuse, une comparaison à une référence et une surveillance de la dérive. Les résultats alimentent des décisions réelles d’exploitation. Le risque dominant devient la dégradation silencieuse : plus le dispositif est utilisé, plus une dérive non détectée se propage loin. La condition pour progresser est l’industrialisation complète — versionnement, traçabilité des prédictions, procédures de réentraînement documentées.

Au cinquième niveau, la boucle se referme : les modèles alimentent l’exploitation, les retours des équipes corrigent les modèles, et les enseignements tirés du parc en service remontent vers la conception des opérations suivantes — choix d’équipements, dimensionnement, instrumentation prévue dès le projet. C’est le seul niveau où l’organisation apprend réellement de son patrimoine. Il exige une discipline de collecte et de restitution que peu de structures maintiennent, et son risque principal est l’abandon progressif de cette discipline dès que la pression opérationnelle augmente.

Perspectives : ce qui est disponible et ce qui reste expérimental

Quelques évolutions méritent d’être suivies, en distinguant soigneusement ce qui est utilisable aujourd’hui de ce qui relève de la démonstration.

Les modèles de fondation appliqués aux séries temporelles constituent la piste la plus discutée. L’idée est d’entraîner un modèle général sur d’immenses volumes de séries de toutes origines, puis de l’adapter à un bâtiment particulier avec très peu de données. Si elle se confirme, cette approche répondrait au problème le plus structurant du domaine — la rareté des données par bâtiment. Les résultats publiés sont encourageants sur des cas généraux et restent à confirmer sur les spécificités du bâtiment, où les régimes de fonctionnement et les usages sont fortement contextuels. La prudence commande de considérer cette voie comme prometteuse et non comme acquise.

L’usage des modèles de langage dans l’exploitation progresse rapidement sur des tâches périphériques mais réellement utiles : interroger un historique en formulant une question, rédiger un compte rendu d’intervention à partir de notes, retrouver une information dans un fonds documentaire, expliquer un signalement technique à un interlocuteur non spécialiste. La limite est constante et doit être répétée : ces modèles composent ce qui est plausible, ils ne calculent pas. Les architectures qui les contraignent à produire une requête vérifiable, dont le résultat chiffré provient ensuite d’un calcul classique, sont nettement plus solides que celles qui les laissent répondre directement sur des valeurs.

L’hybridation entre physique et apprentissage progresse également, avec des approches intégrant des contraintes physiques directement dans l’ajustement du modèle. Elles répondent à deux faiblesses simultanément : le besoin de données, réduit par la structure physique, et l’extrapolation, mieux contrôlée. C’est probablement la direction la plus pertinente pour le bâtiment, précisément parce qu’elle exploite le fait que le domaine dispose d’une théorie physique solide — un avantage que peu de secteurs possèdent.

Enfin, la question déterminante des prochaines années ne sera vraisemblablement pas algorithmique mais instrumentale. La performance des méthodes est aujourd’hui limitée par la disponibilité et la qualité des mesures, non par la sophistication des modèles. Une organisation qui prévoit son instrumentation dès la conception, qui impose des conventions de nommage des points dans ses marchés d’exploitation et qui garantit contractuellement l’archivage et l’accès à ses données prépare bien mieux son avenir que celle qui investit dans le dernier algorithme disponible.

Conclusion : une compétence de lecture avant d’être une compétence technique

Le machine learning ne demande pas aux professionnels du bâtiment de devenir statisticiens. Il leur demande d’acquérir une compétence de lecture : savoir reconnaître une question bien posée, distinguer une performance mesurée d’une performance annoncée, repérer une fuite de données, identifier le compromis entre fausses alertes et cas manqués, et exiger que l’on précise le domaine de validité d’un modèle. Ces réflexes s’acquièrent en quelques heures et permettent d’évaluer la quasi-totalité des propositions du marché.

Ils conduisent souvent à une conclusion inattendue. Une part importante de la valeur attribuée à l’intelligence artificielle dans le bâtiment provient en réalité de ce qui la précède : disposer de données archivées, documentées et accessibles, savoir ce que mesure chaque point, connaître le fonctionnement réel de ses installations. Les organisations qui font ce travail obtiennent des résultats substantiels avec des méthodes descriptives simples, puis intègrent sans difficulté des modèles prédictifs le jour où un besoin précis le justifie. Celles qui l’ont sauté achètent des modèles qui apprennent des relations dans des données dont personne ne connaît la signification.

Reste une question de fond, que le secteur devra affronter. Ces méthodes reposent sur l’hypothèse que le passé renseigne sur l’avenir. Or les bâtiments entrent dans une période où cette hypothèse s’affaiblit : les régimes climatiques se déplacent, les usages se transforment, les rénovations modifient les comportements thermiques, les réglementations évoluent. L’apprentissage automatique restera précieux pour détecter ce qui s’écarte de l’habituel et pour exploiter ce que l’on observe. Mais dans un monde où l’habituel change, la connaissance physique du bâtiment redevient la compétence la plus durable — et c’est peut-être la meilleure nouvelle de ce guide pour ceux à qui il s’adresse.

Questions fréquentes sur le machine learning dans le bâtiment

Faut-il savoir programmer pour comprendre et encadrer un projet de machine learning ?

Non. Les compétences décisives pour un professionnel du bâtiment sont la formulation de la question métier, la connaissance des données disponibles et de leurs défauts, la compréhension du fonctionnement physique de l’installation et la capacité à lire une évaluation. Aucune ne demande de programmer.

La programmation devient nécessaire pour construire soi-même les modèles et les industrialiser. Beaucoup d’organisations font un choix intermédiaire pertinent : elles internalisent la compréhension et le pilotage, et confient la construction technique à un prestataire ou à une équipe spécialisée. Ce partage fonctionne bien à condition que la question métier et les critères d’évaluation restent du côté du bâtiment.

Combien de données faut-il pour commencer ?

La question se pose mal en nombre de lignes. Ce qui compte est le nombre de situations distinctes couvertes. Pour un modèle de consommation, un cycle annuel complet constitue un minimum pratique, car il faut avoir observé chaque saison ; deux à trois années permettent de distinguer ce qui est régulier de ce qui était particulier à une année.

Pour une détection d’anomalies non supervisée, quelques mois de fonctionnement représentatif peuvent suffire, puisqu’il s’agit d’apprendre l’habituel. Pour une prédiction de pannes en revanche, ce n’est pas la durée qui compte mais le nombre d’événements observés : quelques dizaines de défaillances documentées au minimum, ce qui suppose généralement de raisonner sur une flotte d’équipements plutôt que sur un équipement unique.

Quelle est la différence entre intelligence artificielle et machine learning ?

L’intelligence artificielle est le terme le plus large : elle recouvre l’ensemble des techniques visant à faire accomplir par une machine des tâches associées à l’intelligence humaine, y compris des systèmes entièrement fondés sur des règles écrites par des humains, sans aucun apprentissage.

Le machine learning en est un sous-ensemble : les techniques dont le comportement est dérivé de données plutôt que programmé explicitement. L’apprentissage profond est lui-même un sous-ensemble du machine learning. Cette hiérarchie est normalisée, notamment par les normes ISO/IEC 22989 et ISO/IEC 23053 publiées en 2022. En pratique, la distinction importe surtout pour une raison : beaucoup de systèmes vendus comme relevant de l’intelligence artificielle dans le bâtiment sont en réalité des moteurs de règles expertes, ce qui n’est nullement un défaut — c’est souvent préférable — mais change entièrement les questions à poser.

Comment savoir si une performance annoncée est crédible ?

En exigeant quatre précisions. Sur quelles données la performance a-t-elle été mesurée, et ces données étaient-elles strictement séparées de celles ayant servi à l’entraînement ? À quelle méthode de référence simple se compare-t-elle sur le même jeu ? Chaque variable utilisée sera-t-elle réellement disponible au moment de la prédiction en exploitation ? Et cette performance a-t-elle été observée en fonctionnement réel, sur quelle durée ?

Une performance exceptionnelle s’explique bien plus souvent par une fuite de données ou par un jeu de test contaminé que par une supériorité technique. Poser ces quatre questions revient à demander un procès-verbal d’essai plutôt qu’une plaquette commerciale, et un fournisseur sérieux y répond volontiers.

Le machine learning peut-il remplacer une simulation thermique dynamique ?

Non, car les deux répondent à des questions différentes. Une simulation physique fonctionne sans historique, ce qui la rend indispensable en conception et pour évaluer une situation qui n’a jamais existé — un scénario de rénovation, un changement de système, un climat futur. Un modèle statistique exige un historique et reste valide uniquement dans le domaine observé.

En exploitation, la combinaison des deux est généralement supérieure à chacune prise isolément. Les approches de type boîte grise, qui conservent une structure physique dont certains paramètres sont ajustés sur les mesures, offrent souvent le meilleur compromis : elles restent interprétables, demandent moins de données qu’une approche purement statistique et s’adaptent au comportement réel du bâtiment.

Qu’est-ce que le surapprentissage et comment le repérer ?

Le surapprentissage désigne un modèle qui a mémorisé les particularités et le bruit de ses exemples au lieu d’en extraire la régularité. Il obtient une performance excellente sur les données d’entraînement et médiocre sur toute donnée nouvelle.

Il se repère par une comparaison simple : la performance sur les données d’entraînement et celle sur un jeu de test indépendant. Un écart important entre les deux est le symptôme. C’est précisément pour cette raison que l’on sépare les données avant tout entraînement et que le jeu de test ne doit être utilisé qu’une seule fois, à la fin. Un fournisseur qui ne présente qu’un seul chiffre de performance, sans préciser sur quel jeu il a été obtenu, ne permet pas de vérifier ce point.

Peut-on utiliser un modèle prédictif pour piloter directement une installation ?

Techniquement oui, mais jamais sans encadrement déterministe. Toute commande issue d’un modèle probabiliste doit être bornée par des sécurités qui ne dépendent pas du modèle : plages de consigne, limites de température, verrouillages de sécurité, et retour automatique à un mode dégradé sûr en cas d’indisponibilité ou de résultat aberrant.

L’usage le plus mature consiste d’ailleurs à faire prédire une grandeur — un besoin de relance, une charge attendue — qui alimente ensuite une régulation classique et vérifiable, plutôt qu’à laisser le modèle commander directement. Cette architecture conserve une chaîne de responsabilité lisible, ce qui est déterminant si un incident survient.

Les données de mon patrimoine peuvent-elles servir à entraîner les modèles d’un fournisseur ?

C’est une question contractuelle qui doit être tranchée explicitement, car elle est rarement traitée par défaut. Les données d’exploitation d’un patrimoine décrivent ses vulnérabilités : horaires réels d’occupation, équipements critiques, périodes de faible surveillance, faiblesses techniques.

Le contrat doit préciser le lieu d’hébergement, la durée de conservation, les conditions de réutilisation pour l’entraînement de modèles destinés à des tiers, les droits sur les modèles produits et les conditions de restitution en fin de contrat. Si des données d’occupation ou de présence sont concernées, le régime de protection des données à caractère personnel s’applique et impose des principes de minimisation, d’agrégation et d’information des personnes.

Par où commencer concrètement dans une organisation ?

Par un inventaire des données plutôt que par un projet. Vérifiez ce qui est réellement archivé, sur quelle profondeur, avec quelle granularité, et si l’extraction peut être automatisée. Vérifiez également que la signification de chaque point de mesure est documentée. Cet inventaire réserve presque toujours des surprises, et il détermine ce qui est possible.

Choisissez ensuite un premier périmètre étroit, sur un besoin dont l’absence de réponse coûte réellement quelque chose aujourd’hui, et avec un utilisateur identifié qui s’engage à se servir du résultat. Commencez par une méthode descriptive simple avant tout modèle : il n’est pas rare qu’elle suffise, et c’est un excellent résultat plutôt qu’un échec.

Faut-il un cadre de gouvernance de l’intelligence artificielle pour une structure de taille moyenne ?

Oui, mais proportionné. Une structure de taille moyenne a besoin de quatre éléments : un inventaire des systèmes apprenants en service avec leur responsable ; une règle claire sur ce qui peut être décidé automatiquement et ce qui exige une validation humaine ; une politique explicite sur les données transmises à des tiers ; et une trace des validations sur les décisions engageantes.

La norme ISO/IEC 42001, publiée fin 2023, fournit un cadre de management certifiable pour les organisations qui en ont l’usage, et la norme ISO/IEC 23894 des lignes directrices sur la gestion des risques. Le cadre volontaire du NIST, organisé autour des fonctions Govern, Map, Measure et Manage, permet d’organiser cette réflexion sans formalisme excessif. Les organisations opérant dans l’Union européenne doivent par ailleurs vérifier la qualification de leurs usages au regard du règlement européen sur l’intelligence artificielle, dont le calendrier continue d’évoluer.

Références techniques et sources officielles

Sources consultées et vérifiées le 18 août 2026.

Normalisation de l’intelligence artificielle

• ISO/IEC 22989:2022, Information technology — Artificial intelligence — Artificial intelligence concepts and terminology, publiée en juillet 2022, amendements en cours d’élaboration — iso.org/standard/74296.html
• ISO/IEC 23053:2022, Framework for Artificial Intelligence (AI) Systems Using Machine Learning (ML), publiée en juin 2022, amendements en cours d’élaboration — iso.org/standard/74438.html
• ISO/IEC 23894:2023, Information technology — Artificial intelligence — Guidance on risk management, publiée en février 2023 — iso.org/standard/77304.html
• ISO/IEC 42001:2023, Information technology — Artificial intelligence — Management system, publiée le 18 décembre 2023 — iso.org/standard/42001
• NIST, AI Risk Management Framework (AI RMF 1.0), publié le 26 janvier 2023, fonctions Govern, Map, Measure, Manage ; profil consacré à l’IA générative publié le 26 juillet 2024 — nist.gov/itl/ai-risk-management-framework
• Commission européenne, calendrier d’application du règlement sur l’intelligence artificielle — ai-act-service-desk.ec.europa.eu

Mesure de la performance énergétique et vérification

• ASHRAE Guideline 14-2023, Measurement of Energy, Demand and Water Savings, addendum a publié le 29 octobre 2025 — ashrae.org
• Efficiency Valuation Organization, International Performance Measurement and Verification Protocol (IPMVP) — evo-world.org
• Efficiency Valuation Organization, publication des IPMVP Core Concepts 2022 — evo-world.org

Travaux de référence sur la prévision énergétique par apprentissage

• The ASHRAE Great Energy Predictor III competition: Overview and results, Science and Technology for the Built Environment, volume 26, numéro 10, 2020 — 1 448 bâtiments, 2 380 compteurs, 3 614 équipes de 94 pays — research-hub.nrel.gov
• Limitations of machine learning for building energy prediction: ASHRAE Great Energy Predictor III Kaggle competition error analysis, Science and Technology for the Built Environment, volume 28, numéro 5, 2022, préprint en accès libre — arxiv.org/abs/2106.13475

Gestion de l’information et outils

• ISO 19650-1:2018, Concepts et principes de la gestion de l’information, publiée le 7 décembre 2018, actuellement au stade de révision — iso.org/standard/68078.html
• scikit-learn, documentation officielle et guide de la validation croisée — scikit-learn.org et scikit-learn.org/stable/modules/cross_validation.html