Détecter une fuite n’est pas la même chose que la localiser
Sur le réseau d'eau français, les pertes en canalisation sont estimées entre 30 et 40 % des volumes mis en distribution. Autrement dit : près de la moitié de l'eau que l'on produit, traite et met sous pression n'arrive jamais chez personne. Elle disparaît sous terre, en silence.Ce silence est le cœur du problème. Un lampadaire qui ne s'allume plus se signale de lui-même dès la nuit tombée. Une canalisation posée il y a quatre-vingt-dix ans qui suinte à trois mètres de profondeur ne se signale jamais — sinon, tardivement, par un écart sur un compteur ou un affaissement de chaussée.C'est dans cet angle mort que l'intelligence artificielle a été appelée à la rescousse, avec une promesse implicite : brancher des modèles sur un réseau pour qu'ils désignent les fuites. La promesse résiste mal à l'examen, non parce que les modèles seraient inefficaces, mais parce qu'elle confond deux opérations distinctes. Détecter une fuite, c'est savoir qu'un réseau perd de l'eau. La localiser, c'est savoir où envoyer une équipe creuser demain matin.Entre les deux s'étend une progression en trois niveaux de connaissance, qui ne mobilisent ni les mêmes données, ni le même niveau d'instrumentation, ni les mêmes outils. L'intelligence artificielle n'intervient utilement qu'au troisième — et seulement si les deux premiers ont été franchis.
"Est-ce qu'on peut vraiment parler de manque d'eau ou de stress hydrique quand on a 40 % de l'eau qu'on veut utiliser qui est déjà perdue sous terre dans nos canalisations ?"
Niveau 1 : une anomalie n'est pas une adresse
Le premier niveau est le plus simple, et c'est celui que l'on saute le plus souvent dans les discussions sur l'IA appliquée à l'eau.Il consiste à savoir qu'il se passe quelque chose. Quelques capteurs de débit ou de consommation, un référentiel de ce qui constitue une consommation normale, et un mécanisme d'alerte lorsque la mesure s'en écarte : le dispositif suffit à établir qu'une fuite existe probablement. La logique est celle de la comparaison à un seuil, pas celle de l'apprentissage statistique.
« Avant de lancer de l'IA sur l'eau pour détecter les fuites, il faut déjà savoir qu'on a des fuites. »
La remarque paraît triviale. Elle inverse pourtant l'ordre dans lequel la plupart des projets sont pensés. La première question n'est pas de savoir comment un modèle pourrait trouver une fuite, mais de savoir de quelles mesures on dispose pour affirmer qu'il y en a une.Ce niveau se conquiert par l'instrumentation, non par l'algorithme. Avant de prédire ou d'optimiser quoi que ce soit, l'apport d'un déploiement IoT sur un réseau d'eau est plus élémentaire : il rend mesurable ce qui ne l'était pas. Et une fois la mesure disponible, l'anomalie se détecte par une soustraction.Reste que l'information produite est incomplète. Elle établit qu'un volume manque. Elle ne dit rien de l'endroit où il manque.
Niveau 2 : le puzzle des débits
La difficulté change alors de nature. Sur un réseau étendu, constater une perte globale ne réduit en rien le périmètre de recherche : la fuite peut être n'importe où sur des dizaines de kilomètres de canalisation.La réponse tient dans la multiplication des points de mesure. Un capteur unique renseigne sur un volume ; il ne dit rien de la manière dont ce volume se dissipe. Plusieurs capteurs répartis aux jonctions du réseau produisent en revanche un jeu de valeurs comparables entre elles. L'information ne naît plus de la mesure, mais de l'écart entre les mesures : ce qui entre dans une branche et n'en ressort pas désigne la portion qui perd de l'eau.
« Si on est capable de monitorer au niveau des régies d'eau les débits d'eau sur différentes jonctions, on est capable de voir en fait ce qu'il manque, tout simplement. Ça devient un puzzle. »
L'image du puzzle décrit exactement le mécanisme. On ne cherche plus si le réseau fuit : on cherche quelle pièce ne s'emboîte pas avec les autres. La sectorisation transforme un problème posé sur l'ensemble du réseau en un problème posé sur un secteur.Le gain opérationnel est considérable, mais il a une limite d'échelle. Équiper toutes les entrées et toutes les sorties d'un réseau constitue une réponse partielle ; sur un réseau très étendu, elle cesse de suffire, parce que le maillage nécessaire pour isoler une portion pertinente devient économiquement déraisonnable. La sectorisation resserre le périmètre de recherche. Elle ne le referme pas.
Niveau 3 : de la zone au chantier
Dans un secteur identifié comme suspect subsistent plusieurs portions de canalisation candidates. La question posée aux équipes devient brutalement concrète : par où commencer ? L'observation du débit atteint ici ses limites, parce qu'elle décrit un flux et non l'infrastructure qui le transporte. Pour aller plus loin, il faut mobiliser des données d'une autre nature : celles qui décrivent le réseau lui-même et le territoire qu'il traverse. Données de SIG, topographie, matériau des canalisations, âge, date et lieu des réparations passées.Ces variables ne sont pas décoratives, et la topographie en offre la meilleure démonstration. Savoir qu'un territoire présente des points bas n'est pas une information géographique : c'est une information mécanique. Les points bas subissent des coups de bélier répétés, qui fragilisent durablement la zone. Un dénivelé devient ainsi un facteur de probabilité de rupture.À ces données patrimoniales, relativement stables, s'ajoutent des variables plus mouvantes — épisodes de pluie, de gel, de chaleur, variations de la demande usager — qui modifient les contraintes s'exerçant sur le réseau à un instant donné.La question adressée au système n'est donc plus « où observe-t-on un écart ? », mais : parmi les portions de réseau de la zone suspecte, lesquelles présentent, au regard de tout ce que l'on sait, la plus forte probabilité d'être concernées ?
Une question d'arbitrage autant que de technique
Ce troisième niveau comporte une dimension que l'approche purement technique laisse échapper. Une fois les hypothèses hiérarchisées, la décision remonte du niveau opérationnel vers les directions et les élus, et les questions cessent d'être des questions de mesure : où intervenir en premier, où engager le budget, quelles portions de réseau cibler dans un programme de renouvellement.Une collectivité ne creuse pas partout où un modèle signale un risque. Elle choisit où creuser d'abord, sous contrainte de moyens. Le livrable attendu n'est donc pas une localisation, mais une priorisation défendable.
Le moment précis où l'IA devient utile
De cette progression se déduit une réponse à la question de départ, et elle est plus restrictive que le discours ambiant.Au premier niveau, l'IA n'apporte rien : une comparaison à un seuil suffit à produire l'alerte. Au deuxième, elle n'est pas davantage nécessaire : l'écart de débit entre deux jonctions relève d'une soustraction, et c'est le déploiement de capteurs, non la sophistication du traitement, qui produit la valeur. Baptiser « intelligence artificielle » l'ensemble de la chaîne reviendrait à masquer ce que l'instrumentation accomplit seule.Le point de rupture se situe au troisième niveau, lorsque le nombre et l'hétérogénéité des signaux à croiser dépassent ce qu'un traitement manuel ou une règle explicite peuvent absorber. Il faut alors mettre en relation des données de flux, des données patrimoniales, des données topographiques et des données d'environnement — des objets qui n'ont ni le même format, ni la même fréquence, ni la même fiabilité. C'est précisément le travail pour lequel un modèle est pertinent : chercher des corrélations entre des signaux de natures différentes, là où l'œil humain ne voit qu'un empilement de couches.Ce que produit ce croisement mérite d'être nommé avec précision. Il ne s'agit pas d'une localisation, mais d'une estimation : une zone resserrée, des segments hiérarchisés par probabilité, une orientation donnée aux équipes chargées d'aller vérifier. Le vocabulaire exact est celui de l'approximation utile, pas de la certitude.Le dernier mètre, lui, reste physique. La détection de fuite sur le terrain mobilise des sondes acoustiques, des capteurs de vibration, des détecteurs d'humidité — un ensemble de dispositifs dont l'IA ne fait pas partie et qu'elle ne remplace pas. Ce que l'analyse de données permet, c'est de dire à quel endroit il vaut la peine d'aller ausculter. C'est déjà beaucoup, sur un réseau de plusieurs centaines de kilomètres.
Ce qui doit exister avant le modèle
Situer l'IA au bout de la chaîne implique une conséquence directe : elle dépend entièrement de ce qui la précède, et les projets échouent presque toujours en amont du modèle.La règle du garbage in, garbage out s'applique ici sans indulgence. Des données incomplètes, incohérentes ou mal structurées en entrée produisent mécaniquement des résultats fragiles en sortie, quel que soit le modèle employé.L'ordre de constitution du patrimoine de données compte autant que sa qualité. Les données froides d'abord — patrimoniales, stables, idéalement issues d'un référentiel partagé entre les services d'assainissement, de voirie et de l'eau, de sorte que la donnée soit unique et non dupliquée en dix versions divergentes dans dix outils. Les données chaudes ensuite, qui supposent des équipements pour les produire et un réseau de collecte pour les remonter.Vient enfin la gouvernance, qui n'est pas une formalité administrative mais une condition d'existence du projet.
« Si vous avez dix logiciels et dix prestataires de capteurs mais que tout ça ne communique pas ensemble, votre IA va être aveugle et elle ne pourra pas faire grand-chose. »
L'aveuglement en question ne tient pas à la qualité du modèle. Il tient à ce que les données ne se parlent pas. Un projet d'IA sur les fuites est d'abord un projet d'architecture de données ; ce n'est qu'ensuite qu'il devient un projet d'IA.
Le maillon terrain
Un dernier facteur décide du sort de ces projets, et il n'est ni technique ni budgétaire.L'expérience d'autres déploiements territoriaux est instructive sur ce point. Sur un projet d'optimisation de la propreté urbaine mené par Eridanis, une partie des données devait être saisie par les agents de collecte, sur un formulaire demandant quinze secondes par corbeille. Négligeable, vu du bureau. Sauf que les agents disposent d'une minute dix par corbeille, et que tout dépassement fait s'écrouler le planning de la journée. Ces quinze secondes, dérisoires vues d'en haut, étaient infranchissables vues d'en bas.La transposition à la recherche de fuites est immédiate. Le niveau de précision théoriquement optimal n'est pas nécessairement le niveau d'information exploitable par une équipe contrainte par le temps, l'accès au réseau et l'organisation de ses tournées. Un projet conçu sans jours de terrain passés avec les agents dont le métier est de chercher et de réparer les fuites produira une sortie techniquement correcte et opérationnellement inutilisable.Une prédiction qui ne débouche pas sur une action ne produit aucune valeur.
Observer, comprendre, agir
La séquence peut se résumer en trois verbes, qui valent bien au-delà du sujet de l'eau.
Observer : Les capteurs de débit signalent une consommation qui s'écarte de la norme. Le réseau cesse d'être une boîte noire.
Comprendre : La comparaison des débits entre jonctions isole un secteur, puis le croisement avec les données patrimoniales et environnementales hiérarchise les hypothèses à l'intérieur de ce secteur.
Agir : L'information remonte vers ceux qui décident où intervenir et où engager les moyens, sous la forme d'options argumentées plutôt que d'une réponse unique.
La question pertinente n'est donc pas de savoir si l'on peut mettre de l'IA sur la détection des fuites. C'est de savoir à quel moment on en a besoin — et la réponse est : plus tard qu'on ne le croit, et à condition que la donnée soit fiable, interopérable et gouvernée.Savoir qu'un réseau perd probablement de l'eau est une information. Savoir dans quel secteur il la perd en est une autre. Savoir où envoyer une équipe demain matin en est une troisième. C'est dans le passage de l'une à l'autre que la donnée prend sa valeur — et seulement dans les derniers mètres de ce parcours que l'intelligence artificielle devient autre chose qu'un mot.
Conclusion : Ne pas commencer par l'outil
La question pertinente n'est donc pas de savoir si l'on peut mettre de l'IA sur la détection des fuites. C'est de savoir à quel moment on en a besoin. Et la réponse, telle qu'elle se dégage de cette progression, est plus tardive que le discours ambiant ne le laisse entendre : pas pour détecter l'anomalie, pas pour isoler le secteur, mais pour hiérarchiser les hypothèses à l'intérieur de ce secteur, lorsque les signaux à croiser deviennent trop nombreux et trop hétérogènes pour être traités autrement.Cette réponse a une conséquence pratique immédiate pour toute collectivité qui envisage un tel projet. Avant de spécifier un modèle, il faut établir où l'on se situe sur l'échelle des trois niveaux. Un réseau qui n'est pas instrumenté n'a pas un problème d'IA, il a un problème de capteurs. Un réseau instrumenté mais non sectorisé n'a pas un problème d'IA, il a un problème de maillage. Un réseau dont les données patrimoniales dorment dans dix logiciels qui ne communiquent pas n'a pas un problème d'IA, il a un problème d'architecture. Dans les trois cas, financer un modèle revient à équiper le dernier étage d'un bâtiment dont les fondations ne sont pas coulées.Ce raisonnement dépasse largement le sujet de l'eau. Il constitue un test applicable à n'importe quel projet d'intelligence artificielle territoriale : quel niveau de connaissance ai-je déjà, quel niveau me manque, et ce niveau manquant relève-t-il vraiment d'un modèle ? Beaucoup de projets présentés comme des projets d'IA sont, à l'examen, des projets de mesure ou de gouvernance de la donnée qui n'ont pas été nommés comme tels.Savoir qu'un réseau perd probablement de l'eau est une information. Savoir dans quel secteur il la perd en est une autre. Savoir où envoyer une équipe demain matin en est une troisième. C'est dans le passage de l'une à l'autre que la donnée prend sa valeur — et seulement dans les derniers mètres de ce parcours que l'intelligence artificielle devient autre chose qu'un mot.
