Les capteurs fonctionnent, les tableaux de bord sont opérationnels, et pourtant la ville reste incapable de répondre à une question simple. Les villes qui piétinent ne manquent pas de technologie, mais d'une vision commune, et ce fossé a un coût qui ne cesse de s'alourdir.

Soirée d'inauguration du nouveau centre opérationnel de la ville. Le mur du fond est recouvert d'une mosaïque d'images en direct : la circulation est fluide, la qualité de l'air est normale, l'équilibre énergétique est assuré, tous les capteurs fonctionnent correctement. Le projet a été mené à bien dans les délais et le budget prévus. Les occupants de cette salle ont toutes les raisons d'être fiers.

C'est alors qu'un cadre pose une question simple : quels sont les quartiers où la situation se détériore, et combien d'incidents graves avons-nous enregistrés cette semaine ?

Un silence s'installe dans la pièce. Non pas parce que le data a disparu. Il est bien là, illuminant le mur. C'est parce que la plateforme de gestion du trafic, le système de sécurité et le flux de données environnementales définissent chacun à leur manière les termes “ incident ” et “ quartier ”, et que personne n'a jamais décidé quelle définition prévalait. La ville peut tout détecter, mais ne peut tirer aucune conclusion.

Il ne s'agit pas d'un bug qui sera corrigé dans la prochaine version. C'est le signe d'un échec spécifique, coûteux et très répandu, et cela n'est presque jamais lié à la technologie.

Le charme du capteur

On comprend aisément comment les villes peuvent en arriver là. Les technologies de détection, de prévision et d’optimisation sont désormais véritablement performantes et faciles à acquérir. Un fournisseur peut mettre en place un modèle de circulation en temps réel dès ce trimestre. Un réseau de caméras signale un incident plus rapidement que n’importe quelle patrouille. Ces capacités sont bien réelles et se développent rapidement ; les dirigeants en concluent donc à juste titre que le plus difficile est en train d’être résolu sous leurs yeux.

Mais la partie que vous pouvez voir et acheter est la plus facile. Elle est très parlante, et c’est précisément pour cela qu’elle attire les budgets. La valeur d’une ville, tout comme celle d’une entreprise, ne réside pas uniquement dans ses outils. Sa valeur réside dans une dimension que n’offre aucune plateforme : le sens commun donné à son data, et la responsabilité quant à l’utilisation qui en est faite. L’instrumentation et le volume de data n’impliquent pas la compréhension ; c’est dans l’écart entre ces deux éléments que se joue la valeur d’une ville intelligente.

“ Les capteurs, les plateformes et les modèles peuvent être acquis par n’importe qui, et c’est précisément pour cette raison qu’ils ne constituent plus un avantage. Cet avantage réside désormais dans le sens qui se cache derrière la technologie : ce que représente le data, et si l’organisation s’accorde sur ce point. C’est quelque chose qu’une organisation doit construire, et non acheter. ” – Ali Farhat, responsable Data Engineering, Artefact

Trois niveaux : l'indicateur, le modèle, le mandat

Nous avons constaté qu’il était utile d’envisager le concept de « ville intelligente » data selon trois niveaux distincts. Chacun d’entre eux répond à un problème différent, chacun a des responsables différents et présente un degré d’automatisation différent.

Le Meter est un système de détection piloté par machine. Télémétrie, vision par ordinateur, prévisions, détection d'anomalies. Un travail structuré avec des résultats mesurables, et le domaine par excellence où il convient d'automatiser à grande échelle. C'est également le domaine dans lequel tout le monde investit excessivement, car c'est celui dont les résultats peuvent être affichés au mur. Le principe est simple : si le signal peut être défini et vérifié à moindre coût, automatisez-le.

Le modèle, c'est le sens commun. Les définitions sur lesquelles chaque organisme doit s’accorder avant que l’on puisse se fier au data, et les points sur lesquels ils divergent discrètement. Une “ zone ” correspond à une aire de stationnement pour l’équipe chargée du stationnement et à un secteur de police pour la sécurité publique, et ces deux délimitations ne coïncident jamais. Un “ incident ” correspond à une perturbation de la circulation pour le réseau routier et à un préjudice causé à une personne pour le système de sécurité. Un “ actif ” correspond à une seule route pour l’autorité routière et à une centaine de segments numérotés pour l’équipe d’entretien. Un mot, deux significations, et les totaux ne concordent jamais. Ce sont ces listes de codes, ces définitions d’indicateurs clés de performance (KPI) et ces correspondances intersystémiques qui permettent à un flux de données de transport et à un système de planification de s’accorder sur le fait qu’ils décrivent la même rue. C’est un processus lent, interdépartemental et peu prestigieux, et aucun fournisseur ne peut le prendre en charge de bout en bout. C’est précisément pour cette raison qu’il est souvent négligé. Le principe est le suivant : l’interopérabilité est une décision, pas un achat.

Le mandat, c'est la responsabilité assumée par les personnes. Data : souveraineté. Conservation des données et vie privée. Le compromis entre surveillance et service. La confiance qui détermine si les citoyens accepteront ou non la prochaine fonctionnalité. La technologie peut contribuer à chacun de ces aspects. Les citoyens doivent en être les maîtres. Le principe est le suivant : veiller à ce que la responsabilité reste entre les mains des êtres humains.

FIGURE 1 – L'indicateur, le modèle, le mandat : le cadre emblématique à trois niveaux, « De la domination des machines à la maîtrise par l'humain », chaque niveau étant assorti de sa définition et de son principe.

Les couches évoluent avec le temps, et c’est normal. À mesure que les outils s’améliorent, de plus en plus de données de détection sont transmises de manière fluide au « Meter », ce qui libère les personnes pour qu’elles se consacrent au jugement que seules elles peuvent porter. Mais les capacités évoluent plus vite que la responsabilité, et le fait qu’une tâche puisse être automatisée ne signifie pas que la décision qui s’y rapporte soit dénuée de contexte. L’échec ne réside pas dans l’automatisation. L’échec réside dans le fait de financer le « Meter », de faire mine de respecter le « Mandate » à l’aide d’une présentation de vision, et de vider le « Model » de sa substance entre-temps.

Même sans la charpente, la tour reste impressionnante vue de la rue. Elle n'est tout simplement pas habitable.

Ce coût a un nom : la dette

Lorsqu’une ville évolue plus vite qu’elle ne normalise le sens, cet écart ne reste pas statique. Il s’accumule, discrètement, à l’instar des intérêts. Nous appelons cela la « dette sémantique » et, à l’instar de la dette technique, elle est invisible dans la démo et se révèle pénalisante au moment de la livraison.

FIGURE 2 – La dette en tant que concept : les capacités d’instrumentalisation devancent la maturité du sens partagé.

Cela se traduit par des coûts concrets pour l’entreprise, et non par une notion abstraite. Des indicateurs clés de performance (KPI) qui sont communiqués mais qui ne peuvent en réalité pas être calculés de bout en bout, ce qui rend le tableau de bord de direction purement décoratif. Des intégrations qui s’enlisent parce que deux systèmes ne parviennent pas à se synchroniser sans qu’une personne ne fasse la transition manuellement entre eux. Des retouches, car chaque nouvelle source ajoutée à une infrastructure incohérente alourdit le travail de nettoyage final. Des risques de non-conformité, découverts trop tard, car la durée de conservation et la responsabilité n’ont jamais été définies. Et le symptôme le plus lent et le plus coûteux de tous : un délai de rentabilisation qui ne cesse de s’allonger, car la plateforme est terminée et la ville ne parvient toujours pas à prendre de décision grâce à elle.

Nous avons vu un modèle data passer tous les contrôles automatisés, sans aucune erreur ni aucun avertissement, tout en restant totalement inutilisable. La structure était correcte, ce qui explique qu’il ait été validé. Mais les listes de codes destinées à contraindre les valeurs étaient vides, dans l’attente d’une confirmation par un responsable métier. Les indicateurs de performance figuraient dans le modèle mais n’étaient accompagnés d’aucune formule ; rien ne pouvait donc les calculer. Les mappages qui auraient permis de faire transiter le modèle data d’une agence vers une autre n’existaient pas. Les champs relatifs à la conservation et à la propriété étaient vides. Tout était au vert, mais aucune décision ne pouvait être prise. Le schéma apparaissait comme terminé, car la valeur ne figurait jamais dans le schéma lui-même. Elle se trouvait dans les centaines d’accords humains que le schéma attendait.

Ce n'est pas une hypothèse

Les échecs qui font la une des journaux ne sont qu'une illustration de ce phénomène à l'échelle locale.

En 2017, Sidewalk Labs, filiale d’Alphabet, a remporté le marché pour la construction d’un quartier intelligent sur les rives du lac Ontario à Toronto, avec pour ambition d’intégrer des capteurs dans l’espace public. Le projet a échoué en 2020. La raison invoquée était d’ordre économique, mais le projet s’effritait depuis deux ans en raison d’une question à laquelle la technologie ne pouvait répondre d’elle-même : qui régit les données data qu’une ville collecte sur ses habitants ? La conseillère en protection de la vie privée du projet a démissionné lorsqu’elle n’a pas pu obtenir la garantie que ces données seraient anonymisées dès leur collecte. Le « Meter » n’a jamais fait l’objet de doutes. Le « Mandate » n’a jamais été défini.

Songdo, construite sur des terres gagnées sur la mer près d’Incheon pour un coût s’élevant à plusieurs dizaines de milliards, a été présentée pendant des années comme la « ville intelligente » modèle, dotée de capteurs et de systèmes automatisés omniprésents. Elle est également devenue le symbole d’un lieu surchargé de dispositifs techniques et étrangement dépourvu de vie, souvent décrit comme sous-occupé. L’instrumentation a fonctionné. Ce qui manquait, c’était la question humaine, plus épineuse, de savoir à quoi servait réellement cette ville. Une instrumentation peut être irréprochable et pourtant ne mesurer qu’un lieu où personne ne souhaite vivre.

Même les villes les plus prudentes découvrent le « Mandat » à leurs dépens. Singapour a lancé un outil de traçage des contacts en cas de pandémie en assurant au public que son système « data » ne serait utilisé qu’à des fins de traçage. Lorsqu’il est apparu par la suite que la police pouvait accéder à ce système « data » en vertu de la législation en vigueur, la levée de boucliers a contraint les autorités à adopter une nouvelle législation pour en restreindre l’utilisation. La technologie avait fonctionné exactement comme prévu. Ce qui n’avait pas été convenu au préalable, c’était la promesse concernant la finalité du data. La confiance se forge dans le cadre du « Mandat », et non dans celui du « Compteur », et dans une ville, ce sont ces moments-là qui déterminent si les citoyens acceptent la fonctionnalité suivante.

FIGURE 3 – Un mot, deux sens.

Les contre-exemples se divisent en deux catégories, qui sont toutes deux instructives.

Certains n’ont jamais contracté cette dette. L’Estonie en est l’exemple le plus frappant. Sa couche d’échange nationale data, X-Road, permet aux systèmes publics de partager des données data en toute sécurité depuis décembre 2001, selon le principe du « once-only » : un citoyen fournit une information à l’État une seule fois, et chaque administration la réutilise au lieu de la demander à nouveau. Le réseau X-tee estonien traite désormais environ deux milliards de requêtes par an. La Finlande a rejoint cette infrastructure centrale en 2015, et depuis 2017, les deux pays la développent conjointement par l’intermédiaire de l’Institut nordique pour les solutions d’interopérabilité, un organisme dont ils sont copropriétaires. Ce modèle a été conçu dès le départ comme une infrastructure, ce qui explique pourquoi chaque service ajouté depuis s’y est naturellement intégré.

D’autres ont délibérément réduit cette dette. Barcelone a redéfini le programme « data » comme un bien civique partagé et a insisté pour que ses plateformes soient au service des habitants, et non l’inverse. Amsterdam et Helsinki sont allées plus loin dans le cadre du Mandat, en publiant des registres publics des algorithmes utilisés par leurs administrations afin que les habitants puissent consulter et contester la logique automatisée qui leur est appliquée. Rien de tout cela n’est anti-technologie. Il s’agit de la responsabilité considérée comme une infrastructure.

L'objection sincère

La partie adverse présente des arguments sérieux, qui méritent d'être examinés de manière impartiale.

Un responsable technologique rigoureux vous dira qu’il est impossible de gérer un data dont vous n’avez pas encore collecté les données, et qu’attendre qu’une douzaine d’agences s’accordent sur chaque définition revient à ne jamais rien livrer. Les normes naissent de l’usage, et non des comités. Installez les capteurs, faites circuler les données data, puis négociez leur signification dès qu’il y aura quelque chose de concret à débattre. Et une partie du travail sur la “ signification ” que les consultants affectionnent tant n’est en réalité qu’une formalité, des débats ontologiques qui durent plus longtemps que le budget et ne changent rien.

Certains aspects de ce raisonnement sont justes. Une ville qui refuse de mettre en place l’instrumentation tant que tous les termes n’ont pas été réglés prendra du retard, et son personnel continuera à effectuer manuellement ce que des machines pourraient faire. Mais ce raisonnement s’arrête une étape trop tôt. L’objectif n’est pas de ralentir le « compteur ». Il s’agit de financer le « modèle » en parallèle, afin que l’instrumentation repose sur une base capable de l’absorber. Faire l’impasse sur le « Modèle » ne supprime pas le travail. Cela revient à le transformer en une dette symbolique et à lui appliquer des intérêts. Toronto et Singapour n’ont pas mis en évidence une faiblesse de la technologie intelligente. Elles ont révélé le coût lié au fait de régler d’abord les questions faciles et de traiter les plus difficiles sous la pression.

Par où commencer ?

Les programmes qui créent de la valeur, plutôt que d'accumuler des dettes, ont tendance à suivre quatre axes d'action.

Financer le modèle en tant qu'axe de travail à part entière, et non comme un simple produit dérivé. Attribuez aux définitions communes, aux listes de codes et aux correspondances intersystèmes un responsable désigné et un budget, en les mettant en œuvre parallèlement au développement de la plateforme plutôt qu’après. Le modèle n’est pas une documentation que l’on rédige à la fin. Il s’agit d’une infrastructure que l’on construit en parallèle.

Mesurez les résultats qu'un citoyen serait en mesure de reconnaître. Ce ne sont pas les capteurs déployés ni les tableaux de bord mis en place qui comptent, mais les réponses apportées aux questions et les services améliorés. Un test simple : si un indicateur clé de performance (KPI) ne peut pas être calculé de bout en bout à partir de données réelles data dès aujourd’hui, ce n’est pas encore un KPI. C’est une intention.

Précisez clairement le mandat avant le déploiement, et non après l'incident. Définissez dès le départ les modalités de propriété, de conservation et d'accès au système data, et veillez à rendre ces aspects visibles lorsque la logique du système touche les citoyens. Il est moins coûteux d'instaurer la confiance que de la rétablir.

TConsidérez l'interopérabilité comme un contrat. Pour tout échange inter-agences, convenez de la source de référence, des définitions communes et de la fréquence des mises à jour avant l'intégration, et non pas au moment de l'escalade.

Ce que ces quatre mesures ont en commun, c'est qu'aucune d'entre elles ne s'achète. Chacune d'entre elles relève d'une décision que quelqu'un doit prendre.

“ Une ville ne devient pas plus intelligente simplement parce qu’elle collecte davantage de données. Elle devient plus intelligente dès lors que les données collectées par le capteur data prennent tout leur sens, que ce sens se traduit par des décisions et que ces décisions produisent des résultats. C’est là la véritable infrastructure, et c’est la seule chose que vous ne pouvez ni acheter, ni automatiser, ni reporter. ” – Roland Debbane, associé, Artefact

Cela vaut aussi bien pour une ville existante qui se modernise que pour une nouvelle ville construite à partir de zéro. La nouvelle ville n’a pas de silos hérités à démêler, ce qui constitue un véritable avantage, mais elle doit mettre en place simultanément le « Meter », le « Model » et le « Mandate », et ce rapidement, alors même que les définitions restent encore à rédiger. La ville existante dispose de ces silos, et avec eux l’avantage de savoir exactement à quelles questions elle ne peut déjà pas répondre. Dans tous les cas, si vous mettez en place le « Modèle » dès le début, les avantages s’accumulent : chaque nouveau service s’intègre parfaitement à une base déjà adaptée. Si vous négligez cette étape, vous passerez des années à payer le prix fort en matière d’interopérabilité sur une plateforme qui semble achevée mais qui est incapable de répondre à une question simple.

De retour au centre des opérations

Imaginez ce même mur de flux de données un an après le lancement d’un programme qui a accompli ce travail peu prestigieux. Le cadre supérieur pose la même question. Cette fois-ci, la salle ne tombe pas dans le silence, car les termes “ incident ” et “ quartier ” désignent une même notion convenue dans tous les systèmes, la formule qui sous-tend l’indicateur est accessible à tous, et il est clair qui est responsable du data et qui doit rendre des comptes concernant cette décision. Les capteurs ne sont pas plus performants qu’ils ne l’étaient lors de la soirée d’inauguration.

La ville a tout simplement appris à donner un sens à ce qu'elle perçoit.

Ce n'est pas un argument pour ralentir le rythme. Les villes qui hésitent à adopter l'IA et les technologies de détection se feront distancer par la concurrence, et leurs habitants en pâtiront. Il s'agit plutôt d'un argument en faveur d'une approche de la « ville intelligente » comme un projet de conception organisationnelle, et non comme un simple marché public, et de financer la couche qu'aucun fournisseur ne vous vendra, car aucun fournisseur n'est en mesure de le faire.

La technologie peut équiper une ville, mais ce sont les gens qui lui donnent tout son sens. Avant de mettre en place votre prochain processus, trois questions vous permettront de déterminer si vous créez une valeur ajoutée ou si vous accumulez une dette :

Qu'est-ce qui doit figurer dans le Mètre? Où doit se trouver le Modèle Quelles informations doivent être partagées avant de pouvoir faire confiance au data ? Qui détient les Mandat, et à qui incombent les conséquences ?