Par Pascal Chevallot, avec l’appui de son harnais d’IA
12 août 2026

Une collectivité peut acheter des capteurs à un prix convaincant et découvrir, quelques mois plus tard, qu’elle a surtout acquis des déplacements, des abonnements, des données à contrôler et une dette de maintenance. Avant de généraliser un pilote IoT, il faut chiffrer la vie du dispositif, y compris son retrait.

Le devis tient souvent sur quelques lignes : capteurs, passerelles, pose, plateforme. C’est précis, comparable, rassurant. Puis le projet vit. Une pile faiblit dans un ouvrage difficile d’accès. Un capteur dérive. Une transmission disparaît. La plateforme reçoit bien une valeur, mais personne ne sait si elle peut encore fonder une décision. La difficulté a quitté le devis. Elle est maintenant dans l’organisation.

C’est à ce moment que la question initiale revient, un peu tard : qu’avons-nous acheté ? Un équipement, une donnée, une alerte, une économie attendue, une meilleure continuité du service ? Déployer les capteurs n’est que le début. La collectivité engage un service instrumenté qu’il faudra peut-être étendre, réduire ou arrêter, et dont quelqu’un devra répondre pendant plusieurs années.

Les référentiels publics commencent à rendre cette durée visible. Le Référentiel général d’écoconception de services numériques, version 2024, comporte notamment des critères sur l’utilité du service au regard de ses impacts environnementaux, la collecte responsable et raisonnée des données, ainsi que la maintenance et le décommissionnement. Deux autres critères portent sur la pérennité des protocoles internet et sur la disponibilité de mises à jour correctives pendant la durée de vie prévue des équipements associés, avec des conditions d’applicabilité propres. Ils ne visent donc pas directement tous les protocoles d’un réseau LoRaWAN ni tous les parcs de capteurs. Le référentiel concerne les services numériques et ne constitue pas, à lui seul, une méthode de coût complet pour un projet IoT. Il pose néanmoins des questions qui rendent difficile une fiction encore courante : celle d’un projet achevé le jour de la réception.

La cybersécurité étend encore l’horizon. Le règlement européen sur la cyberrésilience est entré en vigueur le 10 décembre 2024. Ses obligations principales s’appliqueront à partir du 11 décembre 2027, et les obligations de signalement à partir du 11 septembre 2026. Il impose aux fabricants de produits comportant des éléments numériques des exigences couvrant la conception, le développement et la maintenance, ainsi que le traitement des vulnérabilités pendant le cycle de vie. La Commission a publié des orientations pratiques le 27 juillet 2026. Pour une collectivité acheteuse, cela ne remplace ni l’analyse de risque ni les clauses du marché. Cela oblige néanmoins à regarder la durée de support, les correctifs et la fin de vie avant que le matériel soit scellé dans le terrain.

J’en ai eu une illustration très concrète lors de la réception de gateways LoRaWAN installées pour un réseau mutualisé d’objets connectés. L’une se trouvait dans les combles d’une église. Pour l’atteindre, il fallait obtenir la clé du clocher, faire momentanément arrêter la sonnerie des cloches, puis avancer sur les poutres parce que l’on se trouvait au-dessus du plafond du chœur. Une autre était installée dans un bâtiment de remontées mécaniques : l’antenne sur la façade, la gateway de l’autre côté de la paroi, dans un local technique auquel l’exploitant devait donner accès.

Dans les deux cas, l’équipement était posé et fonctionnel. Mais toute intervention future dépendrait aussi d’un lieu, d’une personne disponible, d’une clé et d’une organisation qui n’apparaissaient pas forcément dans le prix du matériel. Pour les capteurs, les difficultés peuvent être semblables : hauteur, regard de voirie, ouvrage fermé, zone circulée, local occupé ou accès saisonnier. La maintenance commence donc avant la panne, avec une question très simple : le jour où il faudra intervenir, qui pourra réellement conduire le technicien jusqu’à l’équipement, dans quelles conditions et avec quel délai ?

Une fiche de vie plutôt qu’une fausse précision

C’est la raison pour laquelle je préfère une fiche courte à un modèle financier qui donnerait une illusion de précision. Elle ne prédit pas tout. Elle oblige à suivre chaque famille de capteurs depuis la décision attendue jusqu’au retrait, en reliant les coûts à une durée, à un responsable et à une preuve. Les sept rubriques ci-dessous forment un point de départ ; le terrain pourra en imposer une huitième.

1. Usage public attendu. Quelle décision ou intervention la mesure déclenche-t-elle ? À quelle fréquence cette donnée est-elle réellement consultée ? La sortie attendue est une règle d’usage, pas une promesse générale de « territoire intelligent ».
2. Acquisition et pose. Matériel, passerelles, études radio, intégration, génie civil éventuel, sécurisation physique, recette et reprise des installations défaillantes.
3. Connectivité. Abonnements, couverture, itinérance, passerelles, supervision du réseau et scénario en cas d’arrêt ou d’évolution du protocole.
4. Exploitation de la donnée. Stockage, interface, API, contrôles de qualité, faux positifs, archivage, suppression et temps passé par le métier à interpréter la mesure.
5. Maintenance et accès. Piles, étalonnage, nettoyage, vandalisme, pièces, déplacements, habilitations, clés, accompagnement local, contraintes de sécurité et accessibilité réelle du lieu.
6. Sécurité et support. Inventaire des versions, correctifs, gestion des vulnérabilités, comptes d’administration, documentation, durée d’engagement du fournisseur et compétences internes.
7. Retrait. Dépose, effacement ou restitution des données, résiliation des abonnements, recyclage, remise en état et conservation de la connaissance utile.

« Maintenance comprise » ne suffit pas. Il faut savoir pendant combien de temps, avec quel délai d’intervention, quelles exclusions, et ce qui arrive au dispositif lorsque le contrat, le réseau ou la plateforme disparaît. Même bien renseignée, la fiche ne supprimera ni les imprévus ni l’arbitrage. Certains coûts ne seront connus qu’après les premières interventions ; certains bénéfices publics, liés à la sécurité, à l’égalité d’accès ou à la continuité, ne se laisseront pas ramener proprement à un montant. L’outil doit rendre ces incertitudes discutables, pas les dissimuler derrière un total.

Prévoir aussi la possibilité d’arrêter

Un pilote devrait prévoir ses critères de retrait avant la généralisation. Le capteur cesse d’être justifié si sa donnée ne déclenche plus aucune action identifiée, si sa qualité tombe durablement sous le seuil accepté, si le support de sécurité s’arrête, si le protocole devient une dépendance sans solution de continuité, ou si personne n’assume plus son exploitation. Le coût de maintien et celui de remplacement doivent alors être comparés au bénéfice de service encore observé, sans forcer ce bénéfice à devenir un chiffre monétaire lorsqu’il relève de la sécurité, de l’égalité d’accès ou de la continuité.

Tous les besoins de mesure n’appellent pas un capteur permanent. Une campagne ponctuelle, une relève manuelle mieux organisée, l’exploitation d’une donnée déjà disponible ou la correction d’un processus peuvent être plus sobres et plus robustes. Et quand le capteur n’est plus utile, le laisser sur place n’est pas une forme d’économie. C’est seulement différer la dépense et perdre la maîtrise du parc.

Avant d’étendre un pilote, la bonne réunion n’est peut-être pas celle où l’on regarde la carte des objets installés. C’est celle où le métier, la DSI, les achats et l’exploitant ouvrent ensemble la fiche de vie : quelle décision chaque mesure sert-elle encore, combien d’interventions a-t-elle réellement demandé, jusqu’à quand le dispositif sera-t-il maintenu et sécurisé, et qui a le pouvoir de l’arrêter ?

Le prix d’un capteur se négocie. Son coût complet, lui, se gouverne.

Sources

• Mission interministérielle Numérique écoresponsable, « Référentiel général d’écoconception de services numériques, version 2 », dernière mise à jour le 28 mai 2024, notamment critères 1.1, 1.6, 2.7, 3.3 et 3.4.
• Commission européenne, « Cyber Resilience Act », page officielle consultée le 11 août 2026.
• Union européenne, règlement (UE) 2024/2847 du 23 octobre 2024 relatif à des exigences horizontales en matière de cybersécurité pour les produits comportant des éléments numériques.
• Comptoir des Signaux, « Nos expertises ».