Crues et sécheresses sont souvent traitées comme deux problématiques distinctes. Pour les collectivités, elles peuvent pourtant concerner les mêmes cours d’eau, ouvrages, nappes ou réserves et s’appuyer sur une infrastructure de données commune.
Une chaîne efficace associe capteurs de niveau ou de débit, réseau de communication, historisation, données météorologiques et territoriales, définition de seuils et alertes. L’accumulation des historiques permet ensuite d’aller plus loin : comparer les épisodes, identifier les vitesses d’évolution, contextualiser les anomalies et préparer des modèles prédictifs.
L’IA intervient à un stade plus avancé. Les sources étudiées insistent sur un prérequis : une prédiction pertinente suppose des données fiables, suffisamment anciennes, centralisées et interopérables.
De l’étiage à la crue : pourquoi construire une connaissance continue de la ressource ?
Une hauteur d’eau de 40 centimètres n’a que peu de signification lorsqu’elle est observée seule. Elle devient beaucoup plus informative lorsque l’on sait que le même point était à 65 centimètres une semaine auparavant, que la baisse se poursuit depuis trois semaines, que les précipitations restent faibles et que d’autres points du bassin suivent la même trajectoire. Quelques mois plus tard, le raisonnement peut s’inverser : 40 centimètres deviennent 60, puis 90 en quelques heures. La valeur opérationnelle se trouve alors autant dans le niveau atteint que dans la vitesse de variation.
C’est l’une des raisons pour lesquelles le suivi de la ressource gagne à couvrir toute son amplitude. Les enjeux rencontrés autour de l’eau peuvent prendre au moins trois formes : un manque d’eau, un excès d’eau ou une présence d’eau à un endroit où elle devient problématique. Ces configurations renvoient à des décisions différentes, mais elles partagent une même nécessité de connaissance.
Sur un canal, un cours d’eau, une retenue ou une nappe, la surveillance régulière permet d’abord de construire un état de référence. L’étiage peut être caractérisé sur plusieurs mois ou plusieurs années. Les épisodes de remontée deviennent comparables. Les événements inhabituels apparaissent plus rapidement dans les séries temporelles. Cette continuité change aussi la manière d’aborder les épisodes extrêmes : lors d’une crue, disposer uniquement de la dernière mesure oblige à raisonner à partir d’un instantané, tandis que plusieurs heures ou plusieurs jours d’historique donnent accès à une courbe, à une tendance et à une dynamique.
Pour la sécheresse, la temporalité est plus longue, mais le principe reste identique. Une baisse progressive observée sur plusieurs semaines peut être rapprochée des périodes antérieures et des conditions météorologiques qui les accompagnaient. La donnée devient ainsi une mémoire du fonctionnement hydrologique local, et cette mémoire devient indispensable dès que le territoire souhaite aller au-delà de la simple surveillance.
Quels capteurs et quelles données faut-il réunir pour suivre réellement l’évolution de l’eau ?
Le premier niveau technique reste la mesure terrain. Les usages documentés reposent notamment sur des capteurs de niveau, de débit, de consommation ou d’hygrométrie, selon la ressource et l’ouvrage surveillés. Des réseaux IoT, notamment LoRaWAN, sont ensuite utilisés pour faire remonter ces données vers une plateforme centrale.
Pour un suivi de crue ou d’étiage, plusieurs informations peuvent ainsi être distinguées : hauteur ou niveau d’eau, débit lorsqu’il est disponible, évolution du niveau dans le temps, état de nappes, réservoirs ou cuves, pluviométrie et prévisions météorologiques, informations géographiques et topographiques, caractéristiques des ouvrages concernés et historique des événements ou interventions.
Le choix du capteur ne suffit pourtant pas à garantir la qualité du dispositif. Le point de mesure compte autant que le matériel lui-même. Une expérimentation de suivi de niveaux d’eau l’a montré de façon très concrète : pendant une crue importante, un capteur s’est retrouvé lui-même immergé. Il a continué à transmettre pendant l’inondation avant de cesser de fonctionner, conduisant les équipes à envisager un autre emplacement.
Ce retour terrain illustre une contrainte fondamentale : un dispositif destiné à surveiller un événement extrême doit continuer à fonctionner pendant l’événement qu’il est censé observer. La position du capteur doit donc être étudiée au regard du niveau maximal susceptible d’être atteint, de l’accessibilité pour la maintenance, de la résistance du matériel à l’humidité ou à l’immersion, de la qualité de la couverture radio et de la représentativité hydrologique du point choisi.
Le réseau de communication fait lui aussi partie du système de mesure. Les réseaux bas débit de type LoRaWAN présentent un intérêt évident pour des capteurs éloignés, autonomes et transmettant de petits volumes de données, mais le territoire impose ses propres contraintes. Les retours disponibles montrent que les reliefs, vallées encaissées et zones isolées peuvent dégrader la couverture. En milieu plus dense, les bâtiments, leurs matériaux ou encore la végétation peuvent également perturber la propagation radio.
La fréquence de remontée doit enfin être adaptée à l’usage. Une observation destinée à documenter lentement un étiage n’exige pas nécessairement la même cadence qu’un épisode de montée rapide. Le système doit donc permettre d’adapter la programmation des objets et les règles de remontée en fonction des cas d’usage. Les retours de déploiement insistent d’ailleurs sur l’importance, pour les équipes, de pouvoir gérer ces calendriers et paramétrages de manière autonome.
Historiser et croiser les données pour comprendre ce qu’un niveau isolé ne dit pas
Une plateforme recevant une hauteur d’eau toutes les quinze minutes peut rapidement afficher une courbe. La difficulté suivante consiste à lui donner du contexte. Un niveau élevé après trois jours de fortes précipitations n’a pas la même signification qu’une hausse équivalente apparaissant sans événement météorologique particulier. Une baisse de nappe doit être rapprochée des périodes précédentes, des précipitations cumulées ou encore des consommations et prélèvements observés.
C’est précisément cette capacité de croisement qui transforme progressivement une infrastructure IoT en outil de connaissance. Les architectures décrites dans les sources associent plusieurs familles de données au sein d’une même plateforme : SIG, données issues des capteurs, applicatifs métiers, historiques et informations météorologiques. Parmi les usages recherchés figurent notamment le suivi des nappes et des réservoirs ainsi que la corrélation entre météo et qualité de l’eau.
Après plusieurs mois, les données permettent de répondre à des questions nouvelles : à quelle vitesse ce point remonte-t-il habituellement après de fortes pluies ? Combien de jours séparent le début d’une période sèche d’une baisse significative du niveau ? À quel moment une situation comparable avait-elle commencé à devenir problématique ? Quels ouvrages réagissent rapidement et lesquels présentent une plus forte inertie ? Ces réponses dépendent du territoire lui-même.
Un modèle construit uniquement à partir d’une norme nationale ou d’un seuil générique ne restitue pas nécessairement les particularités d’un bassin, d’un canal ou d’une nappe. Les données historiques produites localement permettent justement de caractériser ces réactions. C’est également pour cette raison qu’un projet prédictif ne commence pas avec un algorithme.
Les travaux menés sur d’autres problématiques liées à l’eau formalisent très clairement ce principe : les données statiques doivent être complétées par des données dynamiques provenant de capteurs, puis centralisées dans un environnement cohérent et interopérable. La topographie, le SIG, les historiques, la météo ou les informations patrimoniales peuvent ensuite être croisés pour produire une analyse plus précise.
Historiser signifie aussi conserver les défauts de mesure. Un capteur peut perdre momentanément sa connexion, une batterie peut faiblir, une mesure peut apparaître incohérente et un changement d’emplacement peut introduire une rupture dans la série. Ces événements doivent être tracés. Une interruption de trois heures pendant une montée rapide ne peut pas être interprétée comme une stabilité du niveau, et un remplacement de capteur doit être connu si les caractéristiques de mesure changent.
La qualité d’un futur modèle dépend directement de cette discipline. Le principe « garbage in, garbage out » utilisé pour les projets d’intelligence artificielle prend ici tout son sens : un historique long mais mal qualifié peut être moins exploitable qu’une série plus courte dont la provenance, les ruptures et la qualité sont maîtrisées.
Des seuils à l’alerte : comment transformer une mesure en information opérationnelle ?
Afficher des niveaux d’eau dans un tableau de bord apporte de la visibilité. Pour les équipes chargées d’intervenir, l’information devient réellement opérationnelle lorsque le système sait identifier une situation nécessitant une attention particulière. La définition de seuils constitue donc une étape structurante.
Les plateformes IoT déployées sur les territoires permettent précisément de fixer des indicateurs et de générer une alerte lorsqu’un seuil est franchi afin d’accélérer l’intervention.
Le seuil peut être simple : niveau > valeur définie = alerte. Cette première règle fonctionne pour des situations clairement identifiées, par exemple lorsqu’un niveau connu correspond au début de la submersion d’un ouvrage. Elle montre rapidement ses limites lorsque la dynamique de l’événement devient importante.
Une hauteur de 80 centimètres stable depuis plusieurs heures et une hauteur de 80 centimètres atteinte après une progression de 30 centimètres en quarante minutes correspondent à deux situations différentes. Le système peut alors intégrer plusieurs conditions : niveau actuel, vitesse d’évolution, durée et données externes.
Une première alerte peut être déclenchée lorsque le niveau dépasse une valeur déterminée. Un second niveau peut intégrer la vitesse de montée. Un troisième peut tenir compte d’un cumul de pluie observé ou prévu. La logique peut également être appliquée à l’étiage : une baisse lente et régulière peut être suivie sans déclencher immédiatement une intervention, tandis qu’un niveau franchissant un seuil associé à plusieurs jours sans précipitations peut justifier une vigilance accrue.
La plateforme devient alors un moteur de règles. Une logique simple peut être structurée en plusieurs niveaux : vigilance lorsqu’un niveau inhabituel ou une tendance défavorable est détecté, alerte lorsqu’un seuil métier est franchi, alerte renforcée lorsqu’un franchissement est associé à des conditions météorologiques susceptibles d’aggraver la situation, puis retour à la normale lorsque les conditions définies sont durablement satisfaites.
La complexité doit rester proportionnée aux besoins du service. Un seuil bien défini et compris par les agents peut apporter davantage qu’un algorithme sophistiqué dont personne ne sait expliquer les alertes.
Une alerte qui reste dans l’interface d’une plateforme n’a par ailleurs que peu d’intérêt opérationnel. Il faut définir qui la reçoit, selon quelle criticité, par quel canal et avec quelles informations. Une alerte exploitable doit idéalement fournir le point de mesure concerné, la valeur observée, le seuil franchi, l’heure du franchissement, la tendance récente, les données complémentaires utiles et le niveau de criticité.
La chaîne technique se poursuit donc jusqu’à l’organisation humaine. Le système détecte une situation, les équipes la qualifient et la décision reste rattachée à une procédure métier connue. C’est précisément cette articulation qui permet de gagner du temps en situation tendue.
Quand les historiques permettent de passer de la réaction à l’anticipation
Une alerte répond à une situation déjà observable. L’anticipation cherche à identifier son évolution avant le franchissement du seuil critique. Cette étape exige davantage de données.
Les sources consacrées au passage à l’échelle des projets IoT le rappellent explicitement : une solution d’intelligence artificielle efficace suppose d’abord de disposer d’un historique suffisant. La construction de cet historique précède donc le développement du modèle.
Les usages envisagés autour de l’eau vont déjà dans cette direction : simulation de scénarios de crue ou de sécheresse, prédiction de la demande, détection précoce de pollutions ou croisement entre météorologie, caractéristiques du territoire et données remontées en temps réel.
L’intérêt du prédictif apparaît lorsque plusieurs séries peuvent être mises en relation. Une forte pluie observée en amont peut précéder de plusieurs heures une hausse sur un point surveillé. Une succession de semaines faiblement arrosées peut annoncer un passage sous un niveau d’étiage. Une hausse similaire à celle observée lors d’un événement passé peut permettre d’identifier plus tôt une trajectoire connue.
Le modèle peut alors travailler sur la probabilité d’une évolution. La sortie recherchée peut prendre une forme simple : « au rythme actuel et compte tenu des données météorologiques disponibles, le seuil X pourrait être atteint dans les prochaines heures ».
Pour une collectivité, quelques heures d’anticipation peuvent modifier considérablement l’organisation. Les agents peuvent vérifier un ouvrage, préparer une fermeture de route, sécuriser un équipement ou prévenir les responsables concernés avant que le seuil opérationnel soit effectivement franchi. Sur une sécheresse, l’horizon devient plus long : la projection peut servir à préparer des arbitrages, surveiller plus étroitement certains secteurs ou adapter la gestion de la ressource.
Un modèle prédictif pertinent suppose donc plusieurs briques déjà opérationnelles : capteurs fiables → connectivité → données historisées → qualité contrôlée → données croisées → seuils métier → procédures d’alerte → modèle prédictif.
Sauter directement à la dernière étape fragilise toute la chaîne. C’est ce que montrent également les retours d’expérience sur l’IA appliquée à la gestion de l’eau : la précision vient du croisement des données du territoire, notamment le SIG, la topographie, les caractéristiques patrimoniales, les historiques météorologiques et les données dynamiques issues des capteurs.
À terme, ces données peuvent alimenter des outils plus larges : observatoire territorial de l’eau, modélisation des flux ou jumeau numérique. Les projets recensés envisagent déjà le suivi conjoint des nappes, des réservoirs, de la météo et d’autres informations métiers dans cette perspective.
Conclusion
« Une donnée de niveau, de débit ou de consommation n’a d’intérêt que si elle s’inscrit dans une chaîne complète. Il faut d’abord observer, ensuite comprendre ce que les données racontent lorsqu’on les rapproche dans le temps et avec d’autres informations, puis seulement agir. C’est à ce moment-là que l’on peut commencer à parler de prédictif et d’anticipation. »
Alexis Semmama – Directeur général, Eridanis
Une sécheresse peut se construire pendant plusieurs mois. Une crue peut évoluer en quelques heures. Le temps de réaction change profondément, mais une grande partie de l’infrastructure technique reste commune.
Il faut connaître les points à surveiller, mesurer avec une fréquence adaptée, transmettre les données, conserver les historiques et les rendre comparables. Il faut ensuite contextualiser ces mesures avec la météo, le SIG, les caractéristiques des ouvrages ou les observations terrain. Les seuils permettent de passer de la surveillance à l’alerte. Les historiques suffisamment riches ouvrent ensuite la voie à la simulation et à la prédiction.
Cette progression est déterminante, car l’anticipation d’un risque hydrologique ne naît pas au moment où l’algorithme est déployé. Elle se construit dès la première mesure correctement localisée, historisée et qualifiée.
De l’étiage à la crue, la maturité d’un dispositif se lit finalement dans sa capacité à faire évoluer la même donnée au fil du temps : d’une mesure de niveau vers une tendance, d’une tendance vers une alerte, puis d’une accumulation d’historiques vers une capacité d’anticipation.
