Demande en eau
Dix mille personnes consommant 150 litres chacune demandent 1 500 000 litres par jour et 547 500 000 litres par an. Indiquez la population et la consommation par habitant pour dimensionner un réseau ou comparer une commune à une référence. Gratuit dans votre navigateur.
- Gratuit
- Fonctionne dans votre navigateur
- Sans inscription
- Vos données restent sur votre appareil
Lancer gratuitement
Exemple résolu
- Population
- 10 000
- Litres par habitant
- 150
- Litres par jour
- 1 500 000
- Litres par an
- 547 500 000
- Jours de l'année
- 365
La demande municipale et communautaire en eau est le volume qu'une zone de desserte prélèvera si l'on sait combien de personnes y vivent et combien de litres chacune utilise par jour. Les services d'eau, les urbanistes, les consultants environnementaux et les étudiants en ressources en eau ont besoin de ce produit comme total quotidien et comme total annuel pour dimensionner des usines de traitement, comparer une ville à un référentiel publié de litres par personne et par jour, et placer une année de prélèvements à côté du budget d'un réservoir. Ce calculateur de demande en eau accepte une taille de population et une consommation quotidienne par habitant en litres, les multiplie pour la demande quotidienne, puis multiplie le total quotidien par 365 pour la demande annuelle, les deux en litres. Zéro est admis et renvoie zéro litre, car une zone vide ou un scénario de consommation nulle ne demande vraiment rien.
Comment la demande en eau se calcule à partir de la population et du LPCD
Au premier ordre, la demande communautaire en eau n'est ni un modèle météorologique ni une simulation de réseau de canalisations : c'est le produit de deux grandeurs qu'un planificateur possède déjà ou peut supposer. La population est le nombre de personnes desservies — un décompte de recensement, une projection d'horizon de conception, l'occupation d'un camp de réfugiés ou les résidents d'un lotissement. La consommation quotidienne par habitant est le nombre de litres que chacune de ces personnes utilise en un jour, noté LPCD dans les tables d'ingénierie de l'eau.
Les chiffres publiés vont typiquement d'environ cinquante litres par personne et par jour dans une desserte rurale rationnée, à cent à deux cents dans de nombreux réseaux urbains, jusqu'à trois cents ou plus lorsque l'irrigation extérieure et les fuites de distribution dominent. La demande quotidienne en litres égale la population fois ce chiffre par habitant. La demande annuelle égale le total quotidien fois 365, le décompte civil de jours utilisé pour les budgets annuels de réservoir et d'usine.
Dix mille personnes à cent cinquante litres chacune demandent donc un million cinq cent mille litres en un jour et cinq cent quarante-sept millions cinq cent mille litres en un an. Un quart de million de personnes à cent quatre-vingts virgule cinq litres chacune demandent quarante-cinq millions cent vingt-cinq mille litres par jour.
La méthode n'ajoute pas l'eau non comptabilisée, les charges industrielles en bloc, les facteurs de pointe saisonniers ni les réserves de débit incendie ; cela appartient à un modèle complet de schéma directeur que vous pouvez superposer après avoir cette base. Changez l'une ou l'autre entrée et les deux totaux bougent de concert.
Cette page n'est pas un calculateur d'apport personnel en eau potable, une page de capacité de citerne ni une page de gaspillage d'un robinet qui goutte : celles-là répondent à ce qu'un corps doit boire, à ce qu'un récipient contient ou à ce qu'une fuite a déjà perdu — non à ce qu'une population prélèvera sur le réseau.
Ce qu'il faut saisir : habitants et litres par personne
Une population fractionnaire est admise pour qu'une estimation de milieu d'année telle que 12500.5 n'ait pas à être arrondie d'abord, et un LPCD fractionnaire est admis pour qu'un 137.4 litres par personne et par jour mesuré soit envoyé tel quel. Les champs manquants, chaînes vides, booléens, objets et jetons qui ne sont pas des décimaux simples ou une notation scientifique échouent de la même façon. Zéro est accepté et renvoie zéro litre, parce qu'une zone vide ou un scénario de consommation nulle ne demande vraiment pas d'eau.
Les nombres sont arrondis à douze décimales afin que goldens et clients comparent octet par octet entre exécutions. Si le produit déborde vers Infinity, la tâche échoue plutôt que de renvoyer un volume non fini. L'année est l'année civile exacte de 365 jours utilisée en demande de criblage, non 365.25 et non un calendrier bissextile, de sorte qu'un total annuel est reproductible à partir des mêmes entrées sur chaque machine.
Qui planifie avec la demande en eau d'une commune
Les services d'eau et les ingénieurs municipaux utilisent un calculateur déterministe de demande en eau pour transformer une population de recensement et un LPCD publié ou mesuré en litres quotidiens et annuels à placer à côté de la capacité d'une usine, au lieu de citer un slogan sur ce qu'une ville consomme.
Les campagnes climat et conservation qui demandent de comparer leur ville à une cible de cent litres de LPCD peuvent envoyer les deux mêmes nombres que le visiteur a déjà saisis et afficher le prélèvement annuel sans inventer un taux de consommation. Une validation échouée ne consomme pas le solde. Gardez les requêtes petites, figez les champs arrondis dans les tests, et vous obtenez un produit de demande reproductible sans dresser votre propre intégration de facturation.
Si vous avez ensuite besoin d'un coût en monnaie, multipliez les litres par votre tarif local ; ce point d'accès s'arrête exprès au volume.
Cas d’usage
Demande préliminaire municipale
Transformez une population de recensement et un LPCD publié en litres quotidiens et annuels à placer à côté de la capacité d'une usine ou du budget d'un réservoir.
Questions fréquentes
Comment calcule-t-on la demande en eau d'une population ?
La demande quotidienne en litres égale la population fois la consommation quotidienne par habitant en litres. La demande annuelle égale ce total quotidien fois 365. Dix mille personnes à 150 litres chacune donnent 1,500,000 litres par jour et 547,500,000 litres par an.
Quelle valeur de LPCD devez-vous utiliser ?
Utilisez un chiffre mesuré ou publié de litres par personne et par jour pour la zone de desserte. Les valeurs typiques de criblage se situent près de 50 L dans une desserte rurale rationnée, 100–200 L dans de nombreux réseaux urbains, et 300 L ou plus lorsque l'irrigation et les fuites dominent. Le calculateur ne devine pas le LPCD.
Pourquoi l'année compte-t-elle 365 jours et non 365.25 ?
La demande de criblage utilise l'année civile de 365 jours pour que le total annuel soit reproductible et corresponde aux budgets annuels des services d'eau. Les ajustements d'année bissextile et d'année moyenne 365.25 appartiennent à un modèle de calendrier, pas à ce produit.
Que se passe-t-il si la population ou les litres par habitant sont négatifs ?
Une population négative ou un taux par habitant négatif n'est pas une demande physique. Zéro est admis et renvoie zéro litre. Une entrée invalide n'est pas facturée.
Est-ce la même chose que l'apport personnel en eau, et quel est le coût ?
Non. Cette page estime ce qu'une population prélèvera, non ce qu'une personne doit boire. L'outil du navigateur est gratuit.
Outils associés
Pour les développeurs — accès API
Tout sur cette page est disponible par programmation. Cette section s'adresse aux équipes qui veulent l'intégrer à leurs systèmes ; les autres peuvent simplement utiliser l'outil ci-dessus.
Endpoint
Authentification par jeton Bearer : un seul POST met la tâche en file d’attente, et le résultat vous parvient par webhook ou lien signé.
Appeler depuis votre stack
curl -X POST https://api.kit.forhosting.com/eco/water-demand \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"population":10000,"per_capita_liters":150}'const res = await fetch("https://api.kit.forhosting.com/eco/water-demand", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"population": 10000,
"per_capita_liters": 150
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/eco/water-demand",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"population": 10000,
"per_capita_liters": 150
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/eco/water-demand", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"population":10000,"per_capita_liters":150}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"population":10000,"per_capita_liters":150}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/eco/water-demand", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Exemple de requête
{
"population": 10000,
"per_capita_liters": 150
}Exemple de réponse
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "eco.water_demand",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L’API est asynchrone : chaque appel renvoie un task_id immédiatement, puis vous interrogez l’état à raison d’une requête par seconde.
Tarifs
Le prix est publié, sans tokens ni crédits. Une tâche qui échoue n’est pas facturée.
Erreurs
| HTTP | Code | Signification |
|---|---|---|
401 | unauthorized | Clé API absente ou invalide : vérifiez l’en-tête Authorization. |
402 | insufficient_balance | Solde insuffisant : rechargez votre compte pour lancer cette tâche. |
404 | unknown_type | Type de tâche inconnu : vérifiez le champ type de votre requête. |
429 | rate_limited | Trop de requêtes : ralentissez la cadence, puis réessayez. |
Notes techniques
Une population négative ou un usage par habitant négatif échoue avec invalid_input au lieu d'inventer un prélèvement.
Entrées, unités, alias et comportement d'erreur
Envoyez un objet JSON avec deux nombres finis obligatoires : population, le nombre de personnes de la zone de desserte ; et per_capita_liters, la consommation quotidienne de chaque personne en litres. Chaque champ accepte aussi une chaîne numérique et une courte liste d'alias (pop, people, inhabitants, n, lpcd, liters_per_capita, daily_per_capita, consumption, per_capita) afin que tableurs et formulaires n'aient pas à renommer les colonnes. Toute valeur négative est rejetée : une population négative ou un taux par habitant négatif n'est pas une demande physique, donc la tâche échoue avec invalid_input qui nomme le champ. En cas de succès, la réponse répète population et per_capita_liters résolus, puis indique daily_liters comme population fois LPCD, annual_liters comme daily_liters fois 365, days_in_year toujours égal à 365, une chaîne de formule compacte et l'étiquette de méthode population_times_lpcd_times_365. Il n'y a ni consultation réseau, ni tirage aléatoire, ni dépendance à la date du jour ou aux calendriers bissextiles : les deux mêmes nombres produisent toujours le même JSON.
Où une API de demande en eau justifie son existence
Les consultants qui consignent déjà les populations de zone de desserte peuvent envoyer une tâche par communauté et stocker daily_liters et annual_liters à côté de l'identifiant de la zone sans ouvrir un tableur de facteurs de 365 jours. Parce que l'implémentation est du parse pur de niveau A, chaque appel réussi coûte le prix de base publié $0.002 sans jetons de modèle ni réseau sortant. Si vous avez ensuite besoin de la demande d'heure de pointe ou de jour maximal, appliquez votre propre facteur de pointe à daily_liters ; le produit de base reste auditable et inchangé.
Cas d'intégration
Lots de zone de desserte du consultant
Envoyez une tâche par communauté avec la population consignée et les litres par habitant, puis stockez daily_liters et annual_liters à côté de l'identifiant de la zone.
Widgets de classe et de campagne
Laissez les visiteurs saisir une population et une cible de LPCD et voir la demande quotidienne et annuelle sur un outil en direct qui coïncide avec l'API octet par octet.