Quality Attributes Software: anatomie d’un logiciel de bâtiment

Résumé

Les éléments substantiels disponibles datent surtout de 2007 à 2013. Ils documentent la manière dont Quality Attributes Software présentait iBPortal puis IntelliFace, mais ne vérifient ni une activité officielle actuelle, ni une offre SaaS disponible aujourd’hui, ni le rôle présent d’un opérateur cloud.
Le fil conducteur de ces produits était l’unification de données hétérogènes: rapprocher les coûts prévus et les performances observées, suivre les consommations et fournir des vues utiles aux exploitants. Cette promesse éclaire autant la valeur de l’automatisation que les dépendances créées par les interfaces, les modèles de données et l’historique accumulé.
L’annonce de quatre contrats en 2013 ne prouve ni une mise en service achevée, ni des économies mesurées, ni une relation client actuelle. De même, l’image associée à cet article est un contexte générique d’exploitation et non une preuve concernant QAS.

Consulter la fiche de Quality Attributes Software, Inc dans l’annuaire BTW

Un dossier à lire au passé sans le réduire à une curiosité

Quality Attributes Software se prête mal au portrait conventionnel d’un éditeur actuel. Les principales pièces publiques décrivent des lancements, un partenariat technologique, une prise de participation et des contrats annoncés entre 2007 et 2013. Elles ne fournissent pas le socle plus récent qu’il faudrait pour présenter une offre en activité: site officiel vérifié, catalogue courant, conditions de service, tarification, engagements de disponibilité, politique de support ou références de déploiements encore exploités.

Cette limite temporelle n’autorise pourtant pas à conclure que l’entreprise n’exerce plus aucune activité. Elle impose une formulation plus précise: l’activité officielle actuelle de QAS n’est pas établie par les éléments disponibles. L’absence de preuve récente n’est pas une preuve d’absence; elle empêche simplement de transformer une histoire de produit bien documentée à son époque en fiche fournisseur au présent.

Le dossier reste pertinent parce qu’il saisit un moment important de l’informatisation du bâtiment. QAS ne décrivait pas seulement un écran affichant une consommation. Ses annonces plaçaient le logiciel entre plusieurs mondes: conception, équipements mécaniques, exploitation immobilière, données en temps réel, objectifs de développement durable et décisions budgétaires. Cette position intermédiaire est celle d’un logiciel d’entreprise, même lorsque son objet physique est un bâtiment.

Elle produit une question qui demeure actuelle: que reste-t-il lorsqu’une couche logicielle a organisé des données, des comparaisons et des gestes d’exploitation, mais que la continuité du produit devient difficile à vérifier publiquement ? La réponse ne se trouve ni dans la nostalgie technologique ni dans une supposition d’abandon. Elle se trouve dans la structure de la dépendance: formats, connecteurs, séries chronologiques, règles de calcul, tableaux de bord et savoir-faire des équipes.

Lire QAS comme un dossier historique permet donc de distinguer deux temporalités. La première est celle de l’entreprise et de ses annonces. La seconde est celle des systèmes installés, des données conservées et des processus bâtis autour d’eux. La seconde peut survivre à la première, changer de propriétaire, être migrée ou s’éteindre progressivement. Les sources ne disent pas quel scénario s’est produit pour chaque environnement QAS; elles montrent pourquoi cette question aurait dû faire partie du choix logiciel dès l’origine.

En 2007, le logiciel voulait relier conception et exploitation

Le premier jalon solide remonte à mai 2007. Quality Attributes Software et Beck Technology annonçaient l’intégration d’iBPortal, présenté comme un portail intelligent du bâtiment, avec DProfiler et les données de coûts RSMeans. L’objectif déclaré était de rapprocher les coûts énergétiques prévus pendant la conception de ceux observés durant la vie du bâtiment.

Cette architecture conceptuelle mérite attention. Un modèle de conception fixe une référence pour des équipements mécaniques; le système d’exploitation recueille ensuite des données réelles; l’écart entre les deux doit aider les responsables à déterminer si les performances restent conformes aux attentes. Le produit n’était donc pas présenté comme une simple archive de relevés, mais comme une boucle entre hypothèse, observation et décision.

Les articles de 2007 attribuaient à iBPortal l’acquisition, la mise en tendance, l’affichage et la production de rapports à partir de données en direct sur l’usage et le coût de l’énergie. Ils évoquaient des catégories d’équipements telles que les centrales de traitement d’air, les groupes froids, les chaudières, les unités de refroidissement, les chauffe-eau ou encore certains moyens de production renouvelable. Ces descriptions rapportent les capacités revendiquées à l’époque; elles ne constituent pas une mesure indépendante de fiabilité, d’exactitude ou de rendement.

L’intérêt de l’intégration résidait dans la continuité du raisonnement. Une estimation établie lors de la conception devait rester consultable après l’ouverture du bâtiment, tandis que les données d’exploitation devaient rendre les écarts visibles. Une telle continuité peut améliorer la discipline de gestion, mais elle dépend d’hypothèses souvent fragiles: nomenclature stable des équipements, unités cohérentes, horodatage fiable, qualité des capteurs et maintien des correspondances entre modèle prévu et installation réelle.

À mesure que le bâtiment évolue, ces correspondances deviennent un actif en soi. Un équipement est remplacé, une zone change d’usage, un compteur est reconfiguré ou une règle tarifaire varie. Si le logiciel ne conserve pas la provenance et la date de ces changements, une comparaison très précise en apparence peut opposer des réalités qui ne sont plus comparables. La valeur ne tient donc pas seulement à la collecte, mais à la gouvernance du sens des données dans le temps.

Ce point annonce déjà le problème du cycle de vie. Un exploitant ne dépend pas uniquement d’un exécutable. Il dépend de la manière dont des années d’observations ont été nommées, rapprochées et interprétées. Migrer le système suppose de préserver ces relations, faute de quoi l’historique peut être exporté tout en perdant sa portée opérationnelle.

IntelliFace élargissait la promesse à l’ensemble des ressources

En novembre 2012, QAS présentait IntelliFace comme un système de gestion des ressources et de l’énergie destiné aux propriétés, installations et campus. Le communiqué associait le produit à l’efficacité énergétique, à la conservation de l’eau, aux émissions de carbone et à la gestion des déchets. Le périmètre s’élargissait: il ne s’agissait plus seulement de comparer un équipement à une base de coûts, mais de proposer une vue transversale des ressources mesurables d’un site.

QAS décrivait IntelliFace comme une application cloud capable de dialoguer avec des systèmes ou plateformes existants, quels que soient leur format ou leur langage, puis de collecter, gérer, analyser et stocker de grandes quantités de données. Cette formulation appartient au discours de lancement de l’entreprise. Elle documente l’ambition d’interopérabilité de 2012; elle ne vérifie ni une compatibilité universelle, ni une capacité mesurée, ni l’existence d’un service cloud QAS actuellement exploité.

La nuance est essentielle. Dans un bâtiment, « se connecter à tout » ne désigne jamais une opération unique. Il faut reconnaître les protocoles, traduire les identifiants, harmoniser les unités, gérer des fréquences de mesure différentes et décider ce qu’un état absent ou incohérent signifie. Chaque raccord apporte une nouvelle source de données, mais aussi une nouvelle dépendance envers un adaptateur et envers la connaissance de la personne qui l’a configuré.

IntelliFace était également présenté comme un moyen de suivre plusieurs bâtiments et plusieurs implantations, avec des tableaux de bord adaptés à différents publics. L’idée est familière aujourd’hui: une même donnée brute peut alimenter la vue d’un technicien, le suivi d’un responsable immobilier ou une communication destinée aux occupants. Pourtant, ces vues ne répondent pas aux mêmes questions. Une synthèse destinée à sensibiliser ne doit pas devenir, sans précaution, la base d’une décision technique ou d’une affirmation d’économies.

Le GreenTouchscreen annoncé avec IntelliFace illustrait ce passage de l’exploitation à la communication. QAS disait vouloir utiliser des données en direct pour informer les occupants et influencer les comportements. La fonction pouvait rapprocher la performance du bâtiment de ceux qui l’utilisent. Elle créait aussi une obligation de clarté: préciser quelles données sont instantanées, lesquelles sont estimées, quelle période sert de comparaison et si un progrès affiché provient d’une baisse réelle, d’un changement d’usage ou d’une modification de méthode.

Le produit se situait ainsi au croisement de trois fonctions: intégrer, interpréter et présenter. C’est précisément cette combinaison qui rend une plateforme difficile à remplacer. Les données peuvent être copiées; les règles qui les transforment en indicateurs et les habitudes qui donnent un sens à ces indicateurs sont plus difficiles à emporter.

L’automatisation franchissait la frontière du bâtiment

Les annonces de QAS appartiennent au domaine de l’énergie, mais leur logique relève de l’automatisation d’entreprise. Le logiciel recueille l’état de plusieurs systèmes, le normalise, le confronte à une référence et le distribue aux personnes qui doivent agir. La matière première est physique, mais la chaîne de décision ressemble à celle d’un système financier, logistique ou industriel.

Cette lecture évite de réduire le produit à un tableau de bord écologique. Lorsqu’une organisation s’appuie sur une plateforme pour repérer un écart, prioriser une intervention ou expliquer une performance, le logiciel devient une surface de contrôle. Il influence la façon dont les équipes découpent le bâtiment, nomment les ressources, attribuent les responsabilités et jugent qu’un problème est résolu.

La concentration apporte une valeur évidente. Des données auparavant dispersées peuvent être comparées; une même définition peut être appliquée à plusieurs sites; un responsable peut observer des tendances sans consulter chaque système séparément. Mais la centralisation concentre aussi les erreurs. Une mauvaise correspondance d’unité, un compteur rattaché au mauvais espace ou une référence obsolète peut diffuser un diagnostic erroné dans plusieurs rapports.

Il faut donc séparer l’automatisation de l’autonomie. Une plateforme automatise certaines opérations lorsqu’elle sait recevoir les données et appliquer les règles prévues. Elle ne rend pas l’organisation indépendante de ses fournisseurs, de ses intégrateurs ou de son propre savoir historique. Au contraire, plus les routines sont efficaces, plus elles peuvent devenir difficiles à examiner lorsque les personnes qui les ont conçues ne sont plus présentes.

Pour un responsable immobilier, la question décisive n’est pas seulement de savoir si le logiciel accepte un flux. Il faut savoir qui possède la définition du point de mesure, qui valide les transformations, qui peut corriger une erreur et comment retrouver la valeur d’origine. Un système qui ne conserve que l’indicateur final simplifie la lecture, mais affaiblit la capacité d’audit et de migration.

Le cas QAS montre donc une forme ancienne mais toujours actuelle de dépendance: l’éditeur ne fournit pas uniquement une fonction, il fournit une manière d’ordonner l’exploitation. Cette manière peut devenir profondément intégrée aux réunions, aux budgets, aux objectifs d’énergie et aux contrats de maintenance. La réversibilité doit alors porter sur le modèle opérationnel autant que sur les fichiers.

Quatre contrats annoncés ne valent pas quatre résultats démontrés

En février 2013, QAS annonçait que quatre organisations avaient conclu un contrat pour utiliser IntelliFace: University of Connecticut, Temple University, Johns Hopkins University et National Rural Utilities Cooperative Finance Corp. Les noms donnent du poids commercial au communiqué et montrent les secteurs visés, notamment les campus et les grands ensembles immobiliers.

La formulation doit cependant rester exactement à son niveau de preuve. Un contrat annoncé confirme qu’une relation commerciale a été présentée publiquement par QAS. Il ne démontre pas que chaque installation a été achevée, que tous les systèmes prévus ont été intégrés, que les utilisateurs ont adopté les tableaux de bord ou que des économies ont été mesurées selon une méthode indépendante.

Il ne permet pas davantage de qualifier ces organisations de clients actuels. Une relation conclue en 2013 peut avoir été déployée, modifiée, remplacée, renouvelée ou arrêtée; aucune de ces suites n’est établie ici. Le passage du futur annoncé au résultat observé exige d’autres pièces: réception du projet, périmètre installé, période de référence, mesures avant et après, changements d’usage, méthode d’attribution et témoignage récent du client.

Cette distinction est particulièrement importante pour l’énergie. Une baisse de consommation peut résulter d’un logiciel mieux utilisé, mais aussi de la météo, d’une occupation moindre, du remplacement d’un équipement ou d’une modification tarifaire. Un tableau de bord peut rendre ces facteurs visibles; il ne prouve pas à lui seul qu’il les a causés. Parler d’économies exige une base comparable et une méthode qui isole autant que possible les influences extérieures.

Un acheteur qui évalue un produit historique devrait donc traiter les annonces de contrats comme un point de départ pour la diligence, non comme sa conclusion. Il demanderait quelles fonctions ont été mises en service, pendant combien de temps, avec quels flux, quelles équipes et quels résultats vérifiables. En l’absence de ces réponses, les quatre noms documentent une ambition de marché, pas une performance.

Le même principe vaut pour le mot « installation ». Dans un logiciel connecté au bâtiment, la mise en service ne se termine pas lorsque l’application est accessible. Elle suppose la qualité des données, la validation des règles, la formation, l’organisation des alertes et le maintien des interfaces. Un projet peut être contractuellement engagé tout en restant opérationnellement incomplet; les sources disponibles ne permettent pas de situer ces quatre cas sur cette trajectoire.

Une prise de contrôle n’établit pas la continuité jusqu’à aujourd’hui

Quelques semaines avant le lancement d’IntelliFace, NetWorth Services annonçait en novembre 2012 avoir acquis une participation lui conférant le contrôle de QAS, alors décrite comme établie à Bayville, dans le New Jersey. Le communiqué présentait l’investissement comme un moyen d’accompagner le nouveau produit et la croissance de l’entreprise.

Cette annonce éclaire le contexte capitalistique de 2012. Elle ne permet pas de reconstruire la chaîne de contrôle ultérieure, de désigner le propriétaire actuel ni d’établir que QAS a continué à fonctionner sous la même forme. Une prise de participation est un événement daté; sa portée présente doit être confirmée par des registres et des déclarations plus récents.

Une autre trace, publiée en 2014 par Silicon Prairie News à propos d’Igor Inc., rapporte que Dwight Stewart et ses cofondateurs avaient quitté Quality Attributes Software en 2011 avant le développement d’Igor. Cette information sert de contexte sur la trajectoire d’un entrepreneur. Elle ne décrit ni le sort d’iBPortal, ni la gouvernance d’IntelliFace, ni l’état opérationnel de QAS après cette date.

Les deux éléments peuvent coexister sans fournir une histoire complète. Des fondateurs peuvent quitter une société avant une nouvelle phase d’investissement; une prise de contrôle peut intervenir sans que les sources publiques racontent tous les transferts de technologie, de personnel ou de contrats. Relier automatiquement ces événements produirait une continuité fictive.

Pour le client d’un logiciel d’infrastructure, les changements de contrôle et de direction devraient déclencher des questions concrètes. Qui détient le code, la documentation et les droits nécessaires aux connecteurs ? Qui assure les mises à jour ? Les compétences clés ont-elles été transférées ? Les contrats autorisent-ils une cession ? Les réponses déterminent la continuité réelle du produit bien davantage que la persistance d’un nom commercial.

Le dossier QAS ne fournit pas ces réponses pour aujourd’hui. Sa valeur est de montrer que le cycle de vie d’un logiciel ne suit pas toujours celui de sa marque. Un produit peut changer de propriétaire, être absorbé, maintenu pour certains clients ou remplacé par étapes. Sans clause de réversibilité et sans copie maîtrisée des données, le client découvre trop tard laquelle de ces trajectoires le concerne.

Les données historiques sont l’actif et le piège

Dans un système de gestion énergétique, l’historique n’est pas un simple volume à archiver. Il permet de reconnaître les saisons, de comparer des bâtiments, de détecter une dérive et de comprendre l’effet d’un changement. Plus la série est longue et cohérente, plus elle peut être utile. Cette utilité crée mécaniquement un coût de migration.

Exporter une suite de valeurs ne suffit pas. Il faut conserver l’identité du compteur ou de l’équipement, l’unité, le fuseau horaire, la fréquence d’échantillonnage, les périodes manquantes, les corrections, la hiérarchie du site et la version de la règle de calcul. Une donnée sans ces attributs peut être lisible tout en étant impossible à comparer honnêtement.

Les références de conception ajoutent une couche supplémentaire. Si iBPortal rapprochait les performances observées d’une base issue de DProfiler, la réversibilité devait inclure non seulement les mesures, mais aussi la définition de cette base et son lien avec chaque équipement. Sans ce lien, le nouvel outil pourrait recevoir l’historique sans pouvoir reproduire les écarts qui avaient guidé les décisions.

Les tableaux de bord créent une autre forme de patrimoine. Une direction peut s’habituer à un indicateur, un seuil ou une agrégation propre à la plateforme. Lors d’une migration, reproduire exactement cet indicateur peut être souhaitable pour la continuité, mais aussi dangereux si son mode de calcul n’a jamais été réexaminé. Le changement de système est alors une occasion de distinguer ce qui doit être préservé de ce qui doit être corrigé.

La dépendance s’étend enfin aux personnes. Un technicien sait qu’un capteur particulier dérive; un intégrateur connaît la raison d’une règle spéciale; un responsable se souvient qu’une rupture de série correspond à des travaux. Si ce savoir reste oral, aucune exportation ne peut le transporter. La documentation des exceptions fait donc partie de la portabilité.

Cette analyse ne prouve pas comment les données de chaque client QAS ont été stockées ou exportées. Elle décrit les exigences que les fonctions annoncées rendent nécessaires. Dès qu’un produit promet de collecter des données hétérogènes et de les transformer en décisions dans la durée, son évaluation doit inclure le chemin inverse: récupérer les valeurs, leurs définitions et les règles qui leur donnent un sens.

Le cloud annoncé en 2012 ne prouve pas un opérateur cloud actuel

Le communiqué d’IntelliFace employait explicitement l’expression d’application cloud. Ce terme situe la manière dont QAS présentait le produit en 2012. Il ne suffit pas à classer l’entreprise comme opérateur cloud actuel, ni à déduire l’architecture qui se trouvait derrière le service.

Pour établir une exploitation présente, il faudrait connaître l’entité qui fournit le service, les environnements hébergés, les sous-traitants, les régions de données, le modèle d’isolation, les sauvegardes, la gestion des accès, les procédures d’incident et les engagements de restitution. Aucun de ces éléments actuels n’est vérifié par les annonces historiques.

La différence entre éditeur, intégrateur et opérateur doit rester visible. Un éditeur peut proposer un logiciel accessible à distance tout en confiant l’infrastructure à un tiers. Un intégrateur peut connecter les systèmes du bâtiment sans administrer l’hébergement. Un opérateur peut assurer la disponibilité sans posséder le produit. Le mot « cloud » ne permet pas d’attribuer automatiquement ces responsabilités à QAS.

Cette séparation a des conséquences pratiques. Si une plateforme n’est plus commercialisée, les données peuvent encore résider chez un hébergeur, sur un serveur du client ou dans une copie d’archive. Si un prestataire change, la marque visible peut rester identique alors que la chaîne opérationnelle a été modifiée. La diligence doit donc identifier les détenteurs réels des accès et des données, et non s’arrêter au nom figurant sur une ancienne annonce.

Le dossier disponible ne vérifie pas non plus un site officiel QAS actuel, un prix, un niveau de service, un dispositif de support ou une preuve d’exploitation récente chez un client. Il ne faut pas convertir ce silence en affirmation de fermeture. Il faut le convertir en seuil de preuve: aucune nouvelle dépendance ne devrait être engagée sur la seule base de ces traces sans confirmation directe, juridique et technique.

La catégorie cloud peut ainsi servir de contexte historique et analytique, mais pas de certificat d’activité. Ce cas rappelle qu’une taxonomie décrit un angle de recherche; elle ne remplace jamais l’attribution précise des responsabilités présentes.

Le cycle de vie doit être conçu avant que la preuve ne s’amenuise

Un acheteur qui aurait évalué iBPortal ou IntelliFace à leur lancement aurait naturellement demandé ce que le produit savait faire. Avec le recul, une deuxième série de questions apparaît tout aussi importante: que se passe-t-il si l’éditeur change de contrôle, si une interface n’est plus maintenue, si une équipe fondatrice part ou si les documents publics cessent d’être actualisés ?

La première protection est un inventaire. Il doit relier chaque source de données au système qui la produit, à l’adaptateur qui la transforme, au propriétaire métier et à l’usage qui en est fait. Cet inventaire permet de mesurer le coût d’une évolution. Sans lui, une interface ancienne peut rester critique simplement parce que personne ne sait ce qui la consomme.

La deuxième protection est un export testé. Le client doit pouvoir récupérer les données brutes, les données corrigées, les métadonnées, les hiérarchies et les règles de calcul dans des formats documentés. L’exercice doit être répété et restauré dans un environnement distinct. Un bouton d’exportation qui n’a jamais servi ne constitue pas un plan de sortie.

La troisième protection est la conservation locale de la connaissance. Les schémas, dictionnaires de données, configurations, versions de connecteurs et décisions d’interprétation doivent appartenir au client autant que possible. La documentation du fournisseur reste utile, mais elle ne doit pas être le seul endroit où réside l’explication d’une série critique.

La quatrième protection est contractuelle. Les droits d’accès, d’extraction, d’assistance à la migration et de conservation temporaire doivent survivre à une résiliation ou à un changement de contrôle dans les limites du droit applicable. Les coûts et délais de sortie doivent être définis lorsque la relation fonctionne, non au moment où la coopération devient incertaine.

La cinquième protection est organisationnelle. Une équipe doit savoir qui décide de maintenir, remplacer ou isoler un composant vieillissant. Faute de propriétaire, le système reste en place par inertie, tandis que les compétences diminuent et que la dette de sécurité ou de compatibilité augmente. Le cycle de vie n’est maîtrisé que lorsque l’organisation peut prendre une décision avant l’urgence.

Ces mesures ne sont pas une critique rétrospective spécifique de QAS. Les sources ne permettent pas de juger les dispositions prises par ses clients. Elles constituent l’enseignement général du dossier: une plateforme de données du bâtiment doit être achetée avec son scénario de continuité, parce que la durée de vie des bâtiments et des historiques dépasse souvent celle d’une version logicielle, d’une équipe ou d’une structure capitalistique.

Les sources plus tardives ne comblent pas le vide QAS

Après la période principale, le secteur de la gestion énergétique du bâtiment a continué d’évoluer. Un dossier Google Patents consacré à un système de gestion énergétique avec fonctions analytiques affiche une priorité en 2016 et nomme Johnson Controls Technology Co comme titulaire. Il montre la persistance de problématiques liées aux séries temporelles et à l’analyse énergétique dans un autre contexte industriel.

Ce brevet ne constitue pas un chaînon de continuité avec QAS. Il ne prouve ni transfert de technologie, ni propriété, ni relation commerciale. La page Google Patents avertit en outre que ses indications de statut juridique et de titulaire peuvent être inexactes et qu’elles ne reposent pas sur une analyse juridique. Elle doit donc être utilisée comme repère du domaine, pas comme histoire de succession.

Deux autres documents accessibles, un rapport d’exploitation 2016 de l’Association of Energy Engineers et un document d’Opportunity Iowa, fournissent des points de contexte institutionnel ou régional. Les éléments disponibles ne permettent pas d’y attribuer un passage spécifique à QAS. Ils ne peuvent donc pas servir à affirmer une activité, un contrat ou une continuité technologique de l’entreprise.

Cette retenue compte autant que les faits positifs. Une source peut être accessible, sérieuse dans son propre périmètre et pourtant ne rien prouver sur le sujet précis. Accumuler des références générales autour d’une entreprise ne réduit pas l’incertitude sur son exploitation présente. Seules des pièces qui nomment clairement l’entité, le produit, la date et la relation pertinente peuvent le faire.

Le centre de gravité du dossier reste par conséquent 2007-2013, avec un complément biographique publié en 2014. Tout récit qui prolongerait automatiquement cette chronologie jusqu’à aujourd’hui dépasserait les preuves. La bonne conclusion est plus utile: identifier ce qui était annoncé, ce qui reste vérifiable et ce qu’un décideur doit encore demander.

Ce qu’un propriétaire de bâtiment devrait exiger aujourd’hui

Face à un logiciel patrimonial de données énergétiques, la première étape consiste à établir l’état réel de l’installation. Quelle version fonctionne ? Où est-elle hébergée ? Qui possède les comptes d’administration ? Quelles sources alimentent encore le système ? Quelles sorties sont utilisées par d’autres applications ou par des rapports réglementaires ? Le nom historique du produit ne répond à aucune de ces questions.

La deuxième étape est de distinguer données brutes, données transformées et décisions. Les mesures d’origine doivent pouvoir être retrouvées; les corrections et agrégations doivent être explicables; les alertes ou objectifs doivent être reliés à une règle versionnée. Cette chaîne permet d’auditer un résultat et de le reproduire ailleurs.

La troisième étape consiste à tester la continuité sans dépendre du fournisseur supposé. Une sauvegarde doit être restaurée, un export doit être interprété et un échantillon de séries doit être rapproché de sa source. L’équipe doit connaître le délai nécessaire pour reprendre les fonctions essentielles, même si les tableaux de bord les plus élaborés ne sont pas immédiatement reproduits.

La quatrième étape porte sur les interfaces physiques. Chaque connecteur vers un système du bâtiment doit avoir un propriétaire, une documentation et une solution de remplacement. Les protocoles ouverts réduisent parfois le coût de sortie, mais une configuration obscure peut recréer une dépendance aussi forte qu’un format propriétaire.

Enfin, toute affirmation sur une offre QAS actuelle devrait être vérifiée directement. Il faudrait confirmer la personne morale, l’autorité du signataire, le droit sur le logiciel, la capacité de support, l’architecture d’hébergement et les références récentes. Tant que ces preuves ne sont pas réunies, le dossier historique peut éclairer un patrimoine existant; il ne peut pas justifier une nouvelle relation SaaS ou cloud.

Cette méthode transforme l’incertitude en travail concret. Elle ne prononce pas un verdict sur une entreprise à partir de sources anciennes. Elle protège la continuité du bâtiment en partant de ce qui peut être contrôlé: données, accès, documentation, contrats et capacité de reprise.

Conclusion: préserver le sens avant de préserver l’outil

Quality Attributes Software a laissé une trace cohérente sur une idée forte. Avec iBPortal, le logiciel devait rapprocher la performance réelle d’une référence élaborée en conception. Avec IntelliFace, il devait fédérer des ressources hétérogènes, analyser leurs données et présenter des vues adaptées aux exploitants comme aux occupants. Dans les deux cas, la valeur venait de la traduction entre le bâtiment physique et une représentation exploitable.

Les sources ne permettent pas de dire que cette offre existe aujourd’hui sous une forme officielle, qu’un service cloud QAS est encore opéré ou que les contrats annoncés en 2013 ont produit les résultats promis. Elles ne permettent pas non plus d’affirmer le contraire absolu. Elles délimitent un dossier historique substantiel et une zone contemporaine non vérifiée.

L’enseignement principal concerne le cycle de vie. Lorsqu’un logiciel devient la mémoire énergétique d’un bâtiment, préserver le fichier ou le serveur ne suffit pas. Il faut préserver le sens des points de mesure, les règles de transformation, les références, les exceptions et les responsabilités. C’est cet ensemble qui rend l’historique utilisable et la migration possible.

Le cas QAS rappelle ainsi une règle simple aux propriétaires, exploitants et directions informatiques: l’automatisation est durable seulement si sa sortie a été conçue. Le produit peut changer, l’entreprise peut évoluer et les preuves publiques peuvent s’amenuiser. Les données du bâtiment, elles, continuent d’accompagner des actifs faits pour durer plusieurs décennies.

Quality Attributes Software: anatomie d’un logiciel de bâtiment devenu dossier historique