IA locale : cartographier les problèmes de rue
Découvrez Kerbside, un outil d’IA locale qui transforme une marche en signalement cartographié. Méthode, limites et enseignements : voyez comment l’adapter.
Quand une marche devient un signalement citoyen grâce à l'IA locale
Un trottoir impraticable, un chantier mal balisé, un arbre qui fait de l'ombre : les habitants voient tout ça au quotidien. Le problème, c'est que la plupart ne prennent pas le temps de le signaler. Il faut s'arrêter, prendre une photo, trouver le bon portail, choisir une catégorie, rédiger un texte... puis recommencer. Au bout de quelques fois, la bonne intention s'éteint.
Kerbside propose une autre façon de faire : parler pendant sa marche, puis laisser un outil local transformer la voix et un relevé GPS en carte et en rapport à relire. Le projet a été réalisé sur un ordinateur portable avec Whisper et Gemma. L'idée n'est pas de "décider" à la place des habitants, mais de réduire la partie pénible qui empêche les observations de circuler.
L'intérêt est aussi très concret. Kerbside pose des questions qu'on ne peut pas esquiver : un petit modèle peut-il donner des observations suffisamment régulières ? Comment limiter les erreurs de localisation ? Et comment traiter des données sensibles sans les envoyer à un service en ligne ? Le projet montre ce que ça peut faire, et surtout ce que ce n'est pas censé résoudre.
De la marche au rapport : le principe de Kerbside
Kerbside commence par un problème d'usage, pas par une technologie. Dans beaucoup de villes, les habitants savent où sont les difficultés de circulation piétonne. Mais transformer une observation isolée en signalement exploitable demande plusieurs manipulations. La friction devient vite trop forte quand les problèmes se multiplient, ou quand il faut remplir un formulaire pour chacun.
Le principe est simple : enregistrer une note vocale et une trace GPS pendant la promenade. Ensuite, l'utilisateur importe ces fichiers dans Kerbside, qui tourne sur son ordinateur. Le traitement produit une transcription, associe des phrases à des points du parcours, puis repère ce qui ressemble à un problème ou à un point positif.
Les résultats peuvent prendre plusieurs formes :
- une carte consultable sur téléphone, avec les observations situées le long de l'itinéraire ;
- un rapport synthétique, trié par niveau de gravité, avec des liens cartographiques ;
- des fichiers CSV et GeoJSON, réutilisables par une association ou un groupe de travail ;
- du texte de signalement que l'habitant peut copier dans un portail ou envoyer à une organisation.
Kerbside ne dépose pas automatiquement une plainte. Une personne relit, corrige les erreurs, ajuste les formulations et vérifie les emplacements avant tout partage. C'est important : l'IA prépare un brouillon, elle ne remplace pas la parole du résident.
Une chaîne de traitement simple, mais pas magique
Le parcours technique suit six étapes. D'abord, l'outil estime l'heure de début de l'enregistrement pour mieux faire correspondre la voix et le trajet. Ensuite, faster-whisper convertit l'audio en phrases horodatées. Chaque phrase est rapprochée du point GPS le plus proche. Gemma, lancé avec Ollama, regroupe les phrases et propose une catégorie, un résumé et un niveau de gravité. Enfin, Kerbside génère les fichiers et ouvre une interface pour relire.
Le projet a été testé sur un ordinateur Windows avec un processeur Intel i5, 16 Go de RAM et sans carte graphique. Dans ces conditions, la transcription d'un enregistrement de 8 min 30 prend environ 30 secondes. Le traitement par Gemma est plus lent : environ 1 à 2 minutes pour 12 phrases. Pour une marche de 96 phrases, cela représente près de 12 minutes de traitement.
Ces chiffres ne valent pas pour toutes les machines, évidemment. Ils donnent toutefois un repère utile : une solution locale peut fonctionner sans matériel "spécialisé", mais le temps de calcul fait partie de l'expérience. Si l'outil protège mieux les données, mais impose une attente, il vaut mieux l'annoncer clairement plutôt que laisser croire à un blocage.
La démonstration publiée repose sur une promenade réelle de 12 minutes effectuée sur un campus en Inde. Le projet ne constitue donc pas, à ce stade, une validation dans une ville française. En revanche, le besoin visé - rendre les observations de terrain plus simples à documenter - existe partout, avec des variantes locales.
Le dépôt et la carte de démonstration sont disponibles sur le projet Kerbside et sa carte en ligne.
Rendre l'IA locale suffisamment fiable
Le défi principal n'était pas de faire "sortir" du texte. C'était d'obtenir des résultats suffisamment réguliers pour que quelqu'un puisse relire sans tout reprendre depuis le début. C'est un point clé pour un outil civique : une carte jolie mais truffée d'erreurs ne fait pas gagner du temps, elle déplace juste l'effort vers la vérification.
Dans la première version, Gemma devait repérer les problèmes en traitant des groupes de 12 phrases. Sur les essais, le modèle fusionnait parfois plusieurs observations sans rapport et en laissait passer d'autres. Et surtout, des exécutions identiques pouvaient produire des sorties différentes. Avec une liste globale, le modèle avait trop de marge pour ignorer certaines lignes.
La conception a ensuite changé : Gemma traite chaque phrase séparément. Le modèle indique d'abord si la phrase décrit un problème, un point positif, l'environnement, ou une parole sans observation utile. Il peut aussi signaler qu'une phrase complète la précédente. Le code rassemble ensuite les séquences d'observations qui décrivent le même problème.
Des règles explicites autour du modèle
Plusieurs choix ont amélioré la fiabilité, sans transformer la demande en roman :
- Numéroter chaque phrase dans chaque groupe. Le modèle renumérotait parfois les phrases au lieu de garder leur index d'origine. Résultat : même des réponses correctes pouvaient être ignorées.
- Demander le résumé avant la gravité. L'ordre des champs compte : le modèle décrit d'abord le problème, puis seulement après il attribue un niveau de sévérité.
- Appliquer certaines règles dans le code. Les drains ouverts, les trous et les regards sans couvercle sont classés comme graves via une règle déterministe. L'équipe a constaté qu'une règle claire et codée tenait mieux qu'un réglage basé uniquement sur la consigne.
- Marquer les positions incertaines. Si le GPS le plus proche est à plus de 30 secondes du moment où la personne parle, l'emplacement est considéré approximatif et mis en évidence pour la relecture.
Ce choix de méthode est transférable à d'autres usages. Le modèle est utile pour interpréter des formulations variées, mais ce n'est pas forcément le bon endroit pour "porter" toutes les contraintes métier. Quand une règle est stable, vérifiable et importante, la coder explicitement peut être plus robuste que demander au modèle de la respecter à chaque fois.
Le test réel révèle ce que les jeux d'essai cachent
Les essais préparés ne reproduisaient pas toute la richesse d'une promenade. En situation réelle, on ne se contente pas de signaler des défauts : on parle aussi de ce qu'on voit (verdure, commerce, terrain de sport), on fait des commentaires, on reprend une idée commencée plus tôt.
Lors de sa première vraie marche, Gemma a produit 47 propositions, dont une quarantaine relevaient surtout du décor. Ajouter des consignes négatives dans la demande a peu amélioré la situation. La solution a été de séparer la décision "nature de la phrase" (problème, appréciation, description de l'environnement, bavardage) de la catégorisation, puis d'écarter ensuite les descriptions et les paroles sans observation.
Après cette modification, la même marche a donné 11 propositions. Six correspondaient à de vrais problèmes. Les cinq autres venaient d'erreurs de transcription : "volleyball court" avait notamment été entendu comme "vulnerable court", et le nom d'un bâtiment avait été transformé en expression qui évoquait un obstacle sur le trottoir. Le modèle avait rendu ces erreurs plausibles, mais la source était fausse.
Le bilan passe donc de 47 propositions à 11, puis à 6 observations retenues après vérification. Ce résultat ne prouve pas que le système sera toujours fiable. Il explique surtout pourquoi l'évaluation sur des données réelles et la validation humaine doivent être intégrées dès le départ.
Un autre incident rappelle aussi une chose simple : la qualité de l'IA ne compense pas des capteurs mal configurés. L'application GPS utilisée n'avait pas l'autorisation de fonctionner en arrière-plan : le téléphone s'est verrouillé et n'a enregistré qu'une partie du parcours. Le rapport indiquait 143 mètres parcourus et plusieurs positions approximatives. Kerbside a signalé l'incertitude au lieu de donner une précision inventée. Le mode de calcul est documenté depuis : il faut autoriser la localisation en continu pendant la marche.
Vie privée, données ouvertes et contrôle humain
Une trace GPS associée à un enregistrement vocal, c'est une donnée sensible. Ça peut révéler un domicile, des habitudes de déplacement, des horaires et parfois l'identité de la personne. Pour demander d'envoyer tout ça à une API distante, il faut des arguments solides - alors que, dans ce cas, un traitement local est possible.
Kerbside exécute faster-whisper et Gemma sur l'ordinateur de l'utilisateur, avec Ollama pour lancer le modèle. L'application locale écoute uniquement sur 127.0.0.1 et le projet ne requiert ni clé d'API ni service dans le nuage. En clair : pendant le traitement, les fichiers audio et GPS restent sur la machine, sauf si la personne choisit ensuite de partager les résultats.
Cette architecture limite les transferts, mais elle ne suffit pas à elle seule à garantir un déploiement conforme au RGPD. La confidentialité dépend aussi de la conservation des fichiers, des droits d'accès à l'ordinateur, de la façon dont les cartes sont publiées et des éléments qui permettraient d'identifier les participants. Une association ou une collectivité qui reprendrait le projet devrait fixer ces règles avant de lancer une collecte à grande échelle.
Partager le minimum nécessaire
Distinguer les données brutes et les résultats relus est une bonne décision. Dans la démonstration, la transcription complète n'est pas publiée dans le dépôt public : seuls les constats retenus après vérification sont partagés. Le principe est simple : publier ce qui sert à traiter le problème, pas tout ce qui a permis de le détecter.
Dans un contexte français ou européen, un déploiement sérieux devrait préciser :
- qui organise la collecte et qui peut consulter les fichiers audio et GPS ;
- combien de temps les données brutes sont conservées, puis supprimées ;
- si les participants peuvent retirer leurs observations ou demander leur suppression ;
- quels détails sont masqués avant de publier une carte ;
- qui vérifie les signalements avant transmission à une mairie ou à un portail.
Le fait d'utiliser des modèles ouverts donne aussi une marge d'autonomie. Les catégories, les règles de gravité et les consignes peuvent être adaptées dans le code. Un groupe pourrait par exemple ajouter des critères sur l'accessibilité, les traversées dangereuses ou les obstacles fréquents. Les sorties en GeoJSON et CSV évitent aussi de dépendre uniquement d'un tableau de bord fermé.
Mais "ouvert" ne veut pas dire "sans responsabilité". Une association qui diffuse une carte doit encore relire les informations, expliquer ses choix et éviter de publier des données qui exposeraient inutilement des personnes. La technologie aide, mais l'organisateur reste responsable.
Une place claire pour la personne
La validation humaine ne doit pas être un correctif "après coup". Elle fait partie du fonctionnement attendu. Une transcription peut confondre un lieu ; un modèle peut transformer une phrase ambiguë en constat catégorique ; le GPS peut placer un point approximativement. La personne sur place reste mieux placée pour dire ce qu'elle a vraiment observé.
Cette répartition est pragmatique : l'IA réduit la saisie et structure les informations, tandis que l'humain vérifie le sens, la localisation et la formulation. Pour un signalement susceptible d'entraîner une intervention publique, cette frontière compte plus que le niveau d'automatisation affiché.
Ce que le projet enseigne aux organisations
Kerbside reste un prototype en logiciel libre, pas un service de signalement municipal prêt à être déployé. Cela dit, la chaîne de traitement offre un cadre utile aux collectivités, associations de riverains, établissements d'enseignement et ONG qui organisent des audits de marchabilité.
La première leçon : partir d'une tâche précise. Ici, l'objectif n'est pas "d'ajouter de l'IA" à la participation citoyenne, mais de réduire le temps passé à transformer des notes vocales en observations structurées. Cette définition permet d'évaluer le résultat : les constats sont-ils plus faciles à produire, à contrôler et à transmettre ?
La deuxième leçon : mesurer la qualité à plusieurs niveaux. Le projet s'appuie sur des jeux d'évaluation, avec des parcours préparés, des phrases découpées et une marche réelle. Sur les trois jeux scénarisés de la version finale, les catégories attendues sont obtenues sans omission ni ajout. La gravité peut toutefois varier, et certains détails - comme le numéro d'un poteau - peuvent être traités comme du bavardage. Les performances sur des cas contrôlés ne remplacent donc pas le terrain.
Pour tester une adaptation locale, une organisation peut commencer petit : un parcours, quelques personnes, une liste de catégories clairement définies, puis une revue systématique des erreurs. Il faut suivre les faux positifs, les observations manquantes, les erreurs de transcription et les décalages de localisation. Ce sont eux qui déterminent le temps de correction, donc l'intérêt opérationnel de l'outil.
Avant d'élargir, vérifier le modèle opérationnel
Le projet imagine des audits de quartier où plusieurs habitants parcourent différentes rues, puis où un organisateur regroupe les constats relus sur une carte commune. Il prévoit aussi des comparaisons avant-après pour distinguer ce qui a été corrigé de ce qui persiste. Ce sont de bonnes pistes, mais elles demandent une organisation en dehors du logiciel : qui rassemble les données, qui traite les doublons, et comment on répond aux participants ?
Une expérimentation peut suivre une grille simple :
- Définir le périmètre. Choisir un type de problème et une zone limitée plutôt que vouloir tout cartographier d'un coup.
- Préciser les catégories. Utiliser des termes compréhensibles pour les marcheurs et exploitables par l'organisme qui recevra le rapport.
- Tester les appareils et les réglages. Vérifier les autorisations GPS en arrière-plan, la qualité des enregistrements et les performances des ordinateurs disponibles.
- Organiser la relecture. Définir qui corrige les erreurs et comment les emplacements incertains sont contrôlés.
- Mesurer le coût complet. Comparer le temps de marche, le traitement, la correction et la transmission, pas seulement la durée d'exécution du modèle.
- Fixer les règles de partage. Déterminer la durée de conservation des données brutes et les conditions de publication de la carte.
Cette approche évite de confondre une démonstration convaincante avec un outil réellement opérationnel. Une solution locale peut réduire la dépendance aux crédits d'API et limiter les transferts de données. En contrepartie, il faut une machine capable d'exécuter les modèles, un temps de traitement acceptable et une personne responsable de l'assemblage des parcours.
L'idée d'un traitement directement dans le navigateur pourrait faciliter l'installation et garder les calculs sur l'appareil de l'utilisateur. Mais ça ne supprime pas les questions de performance, de compatibilité et d'autonomie du téléphone. Là encore, il faut arbitrer selon le public : un outil réservé à un organisateur équipé d'un ordinateur n'a pas les mêmes contraintes qu'une application destinée à chaque habitant.
Conclusion : automatiser le travail, pas la responsabilité
Kerbside montre une piste intéressante pour l'IA appliquée aux usages citoyens : alléger une tâche répétitive, sans prétendre remplacer l'observation ni le jugement humain. Whisper transcrit, Gemma structure, le GPS apporte un contexte. Mais c'est la personne qui a parcouru la rue qui confirme ce qui s'est réellement passé.
Le projet rend aussi visibles les conditions d'un usage crédible : des règles déterministes autour du modèle, des tests avec des données réelles, des incertitudes signalées au lieu d'être masquées, et une architecture qui garde les données sur l'appareil. L'outil n'est pas parfait. Il est surtout plus facile à comprendre et à contrôler.
Si vous travaillez avec une association, un établissement ou une collectivité, commencez par un pilote : lancez un parcours, puis mesurez le temps total, de l'enregistrement jusqu'à la transmission. Vous pouvez aussi consulter le dépôt de Kerbside et sa démonstration cartographique. L'enjeu n'est pas d'automatiser la plainte : c'est de rendre le signalement assez simple pour qu'une observation utile ne reste pas au bord du trottoir.