- Cailloux – État de l’art – Le défi de l’Érosion côtière : Un enjeu majeur pour le littoral
- Cailloux – Blog Enquête Terrain
- Cailloux – Blog Solution Technique
Blog Solution Technique
1. Contexte
Dans le cadre du Projet Conception D’objets Utiles, Accessibles et Durables du cursus Ingénieur de l’IMT Atlantique, notre équipe a choisi d’aborder une problématique environnementale et sociétale majeure : le recul du trait de côte du littoral français.
Comme nous l’avions précédemment étudié dans notre état de l’art, ce patrimoine naturel et économique est en situation critique. L’érosion est largement amplifiée par la pression humaine (urbanisation, tourisme) qui s’ajoute aux phénomènes naturels (tempêtes, montée des eaux). Actuellement, près de 1 720 km de côtes sont affectés, avec des pertes pouvant atteindre un demi-mètre par an, menaçant directement les écosystèmes, les infrastructures et l’économie locale.
Forts de ce constat, et observant le besoin d’une réponse plus structurée et coordonnée entre les différents acteurs locaux, nous avons décidé de concevoir et de réaliser une solution technique innovante. Notre objectif est clair : développer un outil permettant d’optimiser l’efficacité de la réponse collective grâce à une meilleure information, coordination et sensibilisation des parties prenantes.
Notre solution est une application ludique permettant de comprendre les enjeux du recul du trait de côte.
Nous vous présentons ici la conception, la réalisation et les choix architecturaux (matériels et logiciels) de cette solution, ainsi qu’une démonstration de son fonctionnement.
2. Réalisation
A. Description de notre solution
Notre application a été conçue pour maximiser l’impact de la sensibilisation en l’abordant sous un triple angle : elle propose des défis de culture générale, éclaire l’utilisateur sur les conséquences de ses décisions, et visualise les effets du changement climatique via des cartes interactives de l’élévation du niveau marin.
Défis de Culture Générale : Le rendez-vous quotidien de l’information
Cette section est pensée pour ancrer l’apprentissage dans une routine ludique. Les questions de culture générale, entièrement centrées sur la problématique du recul du trait de côte, l’érosion marine et les solutions d’adaptation, sont mises à jour quotidiennement. Ce renouvellement constant garantit que l’utilisateur trouve toujours un intérêt à ouvrir l’application, transformant la sensibilisation en un rituel régulier. C’est un moyen simple et efficace de consolider les connaissances et de mesurer sa progression dans la compréhension des enjeux locaux.
Conséquence des Décisions : Plongez au cœur de l’action collective
Il s’agit du cœur interactif de l’application. Ce module prend la forme d’un jeu de simulation où l’utilisateur incarne le maire d’une ville côtière. Face à des scénarios réalistes (montée des eaux, projets immobiliers, manifestations, budgets limités), l’utilisateur doit prendre des décisions. L’objectif est triple : répondre aux besoins immédiats des habitants, respecter les cadres législatifs de l’État, et préserver la planète. Ce jeu permet de faire l’expérience directe de la complexité de la gestion côtière et d’évaluer l’impact à long terme de chaque choix sur la résilience du territoire.
Carte d’Élévation : Visualiser l’urgence du changement climatique
La carte interactive offre la dimension la plus concrète et percutante de l’application. En utilisant des données géographiques et des projections d’élévation du niveau marin, cette fonctionnalité permet aux utilisateurs de visualiser directement les zones inondables et les territoires potentiellement menacés. Cet outil cartographique est essentiel pour transformer des statistiques abstraites en une réalité tangible, renforçant la sensibilisation et l’urgence d’agir, notamment en ciblant les populations vivant ou travaillant dans ces zones à risque.
B. Outils
Pour réaliser notre projet nous avons utilisé :
- VS Code
- Android Studio
- Expo GO
- Google Maps API
- Expo SDK
- Bibliothèque React Native
C. Réalisations
La conception de notre application a nécessité une approche structurée. Nous détaillons ci-dessous la réalisation de chacune des trois parties de notre application. Ces trois parties sont accessibles via trois boutons disponibles sur l’activité d’accueil de l’application. Les chemins d’utilisation sont les suivants :
Figure 1: Schéma chemins d’utilisation application Cailloux
Pour expliquer plus facilement le principe et le fonctionnement de notre solution, nous avons choisi d’utiliser des diagrammes de classe dans les sections qui suivent. Ces schémas nous permettent de visualiser clairement la logique et la structure de chaque composante du projet. Afin de visualiser la structure complète de l’application, nous présentons un diagramme de classe global.
Figure 2: Diagramme de classe application Cailloux
Sur ce diagramme de classe on repère quatre différents éléments définis tel que :
| Élément | Explication de la notion |
| Classe | Le plan de construction qui définit les informations (les données) et les actions possibles (les fonctions) d’un élément du système. |
| Activité | Un écran unique de l’application mobile (ChallengeActivity, GameL1Activity). C’est l’interface avec laquelle l’utilisateur interagit. |
| Fichier Code | Le fichier contient les instructions de programmation de l’application (le code source). |
| Fichier | Une ressource externe qui n’est pas du code : les fichiers de données JSON (pour les questions et scénarios), les images, les sons. |
Figure 3 : Tableau Notions Diagramme de Classe
Partie 1 : défis de culture générale
Lorsque l’utilisateur clique sur “DÉFI”, il s’ouvre une activité (ChallengeActivity) laissant apparaître la question du jour et ses quatre propositions de réponse.
Diagramme de classe :
Figure 4: Diagramme de classe défis Cailloux
Dans une démarche lowtech, nous souhaitions trouver une manière de stocker les données sans avoir à utiliser un outil de stockage à distance. Ainsi, les 365 questions des défis quotidiens ont été stockées dans un fichier json directement dans le code de l’application. Ce fichier se présente sous cette forme :
{
« question1 »: {
« index »: 1,
« text »: « Quelles sont les principales forces naturelles responsables de l’érosion côtière ? »,
« rep1 »: « L’action des vagues »,
« rep2 »: « La dissolution chimique des roches calcaires »,
« rep3 »: « Les tempêtes et ouragans »,
« rep4 »: « La sédimentation fluviale »,
« correctRep »: 1,
« explan »: « Les vagues exercent une action mécanique continue sur la côte, favorisant le détachement et le transport de matériaux. »,
« source »: « BRGM, 2024 — “Littoral, risques côtiers et changement climatique.” »
},
« question2 »: {…
Face aux contraintes de temps, nous avons fait appel à l’Intelligence Artificielle pour la création de la majorité des questions. Bien que cela puisse impliquer une relecture ou un ajustement ponctuel, le format JSON choisi pour stocker cette banque de 365 défis permet à de futurs administrateurs, même non développeurs, de renouveler ou d’adapter ce contenu très facilement
C’est ce contenu, désormais structuré et facilement administrable au format JSON, qui est mis en œuvre : les informations sont directement récupérées, grâce à la fonction loadQuestionsFromJson, par l’activité ChallengeActivity.
L’activité charge et affiche le défi en s’appuyant sur la classe QuestionData, qui modélise le format des questions issues du fichier externe. Elle utilise ensuite les objets natifs de React Native (boutons, images, textes, etc.) pour présenter la question quotidienne (déterminée par la date du téléphone) et gérer l’interaction. Par exemple, l’activité fait appel aux fonctions du module AudioContext et à des fichiers mp3 stockés dans les assets pour générer des effets sonores de victoire ou de défaite selon la réponse de l’utilisateur.
Partie 2 : jeu de simulation
Cliquer sur le bouton jeu lance une activité de choix de niveau (GameActivity) puis une activité de contexte du niveau 1 (GameContextL1Activity) et enfin l’activité du niveau lui-même (GameL1Activity).
Diagramme de classe :
Figure 5: Diagramme de classe Jeu Cailloux
La partie Jeu de l’application est la partie la plus complexe du projet. Le scénario est basé sur un fichier json de la forme :
[{
« questionText »: « Notre commune… »,
« prevQuestCondition »: [],
« prevRepCondition »: [],
« prevQuestNotCondition »: [],
« prevRepNotCondition »: [],
« caracter »: 5,
« rep1 »: {
« repText »: « Organiser des balades… »,
« price »: -5000,
« happiness »: -10,
« mapChanges »: [],
« overlayChanges »: [],
« incomeChanges »: 0,
« explConseq »: « Ce choix permet d’attirer … »
},
« rep2 »: {
« repText »: « Promouvoir le tourisme »,
« price »: 75000,
« happiness »: 5,
« mapChanges »: [],
« overlayChanges »: [],
« incomeChanges »: 1000,
« explConseq »: « Graniland est plus attractive … »
},
« rep3 »: {
« repText »: « Limiter le tourisme »,
« price »: -20000,
« happiness »: -10,
« mapChanges »: [],
« overlayChanges »: [],
« incomeChanges »: -1000,
« explConseq »: « Ce choix a un impact négatif … »
},
« rep4 »: {
« repText »: « Ne rien faire »,
« price »: 0,
« happiness »: 0,
« mapChanges »: [],
« overlayChanges »: [],
« incomeChanges »: 0,
« explConseq »: « Cette décision n’a aucun impact … »
}
},{…
Nous avons instauré une logique conditionnelle dans le scénario. Les paramètres prevQuestCondition et prevRepCondition déterminent les questions qui doivent avoir été posées et les réponses spécifiques qui doivent avoir été sélectionnées pour que la question actuelle apparaisse. Les versions Not de ces paramètres gèrent les situations où une question ou une réponse passée doit ne pas avoir eu lieu pour déclencher la question en cours.
De même, nous avons instauré des paramètres de changement de la carte mapChanges et overlayChanges qui sont de la forme :
[ {« i »: 2,« j »: 6,« newType »: « h »},
{« i »: 3,« j »: 6,« newType »: « h »}]
Ces changements de carte sont enregistrés dans le code grâce à la classe MapChangeData. GameQuestionData, utilisant GameRepData et MapChangeData, permet de récupérer les informations du json. L’intérêt du json est le même que dans la partie Défi, un administrateur non développeur peut facilement modifier ou créer des scénarios.
La fonction parsGameQuestions de GameQuestionRepository est chargée de la lecture du json et de la création de la liste de questions.
Une question particulière nommée explication permet l’affichage des explications des conséquences aux réponses choisies. Elle est repérée par le code car c’est la seule à utiliser le personnage numéro 0 (la présentatrice). La liste de questions alterne une question réelle et une explication. La liste de questions est ensuite appelée dans GameL1Activity qui affiche l’interface du jeu.
export const Explication = new Q.GameQuestionData(« »,[],[],[],[],0,
new Q.GameRepData(« », 0, 0, [], [], 0, « »),
new Q.GameRepData(« », 0, 0, [], [], 0, « »),
new Q.GameRepData(« », 0, 0, [], [], 0, « »),
new Q.GameRepData(« », 0, 0, [], [], 0, « »))
Les fonctions d’affichage du jeu sont communes à tous les niveaux existants (un seul pour l’instant) et sont répertoriées dans le fichier tsx GameUI. Ce dernier importe directement les ressources graphiques (images des personnages, jauges, tuiles de carte, etc.) depuis les assets. En revanche, les fichiers audios sont appelés directement depuis GameL1Activity. Ce choix a été fait car ils sont exclusivement déclenchés par la modification des variables d’état de l’activité (comme le budget ou la carte) et non par l’interface d’affichage elle-même. Leur lecture est assurée par des fonctions provenant du tsx AudioContext, le même module que celui utilisé pour la partie “Défis”.
La fonction HandleSelectRep est la plus importante de l’activité de jeu, elle apparaît à chaque fois que l’utilisateur clique sur une réponse. La fonction assure le déroulement du scénario en distinguant deux types de questions. Si la question est à un indice pair dans la liste de questions, il s’agit d’une véritable question. Les quatre boutons de choix sont alors affichés en plus du texte de question. Au contraire, si l’indice est impair c’est que la question est en réalité une explication à la question précédente. Dans ce cas seul le premier bouton de réponse est affiché avec le texte “Suivant”. La question de type explication n’a jamais d’effet sur le jeu, c’est seulement un texte. L’utilisateur clique simplement sur suivant quand il a fini de lire pour passer à la question suivante qui nécessitera une réponse.
Certaines vraies questions peuvent également être de type ‘événement’ renseigné par le fait qu’elles sont présentées par le personnage 0 alors qu’elles ont un indice pair dans la liste. HandleSelectRep est alors conçu pour n’afficher qu’un seul bouton, la seule issue laissée par l’événement. A l’inverse d’une explication, cette issue a réellement des conséquences sur l’état du jeu. Dans le cas d’une “question évenement”, on considère que l’explication est déjà dans le texte de la question. HandleSelectRep est donc conçu pour sauter l’explication suivante.
Une dernière fonctionnalité de HandleSelectRep est d’assurer la cohérence du scénario. Elle utilise la fonction “respects” (définie dans GameUI) pour vérifier si les conditions de prérequis d’une question sont remplies. Ces conditions incluent la vérification des questions/réponses qui doivent avoir eu lieu (prevQuestCondition et prevRepCondition), ainsi que celles qui ne doivent pas s’être produites (prevQuestNotCondition et prevRepNotCondition). Si la fonction respects renvoie une non-validation, la question et son explication sont automatiquement sautées.
L’activité de jeu (GameL1Activity) se termine immédiatement dès qu’une condition de défaite est atteinte : soit le budget tombe à zéro (n’importe quelle année), soit la satisfaction citoyenne passe sous les 50% (lors d’une année électorale). La fermeture de l’activité déclenche alors un retour vers l’écran de contexte (GameContextL1Activity), auquel est transmis un ordre de modification. Cet ordre adapte l’affichage (changement du fond, lancement de la musique de défaite et texte explicatif) en fonction de la raison de la défaite (Banqueroute ou non-réélection).
Dans le cas où l’on atteint la fin du scénario sans aucune défaite, l’activité GameL1Activité est fermée. Elle transmet alors à GameContextL1Activityun ordre de modification correspondant à la victoire (musique de victoire, fond vert, etc.).
Partie 3 : cartes interactives
Lorsque l’utilisateur clique sur « Donnée », une activité DataActivity s’ouvre, lui permettant de sélectionner l’année de projection souhaitée dans le futur (0, 50, 100 ou 200 ans). A chaque choix correspond une nouvelle activité (CurrentDataActivity, 50DataActivity…).
Diagramme de classe :
Figure 6: Diagramme de classe Carte Cailloux
Les quatre activités sont configurées de la même manière. Elles utilisent l’API Google Maps de sorte à afficher une carte du monde sur laquelle on peut se déplacer. On en reste là pour CurrentDataActivity car il s’agit juste de l’état de la carte actuelle. Dans les trois autres cas, l’activité importe les informations d’un fichier json correspondant. Ils sont de la forme :
{
« id »: « zone_50y_1 »,
« coordinates »: [
{
« latitude »: 42.54177440109096,
« longitude »: 3.051441054077814
},{
« latitude »: 42.541792380354515,
« longitude »: 3.051441069917069
},{
« latitude »: 42.54177441280101,
« longitude »: 3.051416740695078
},{
« latitude »: 42.54177440109096,
« longitude »: 3.051441054077814
}]},
Chaque zone correspond à une surface de terrain submergée par les eaux de la mer. L’API permettant de créer des surfaces vectorielles de surlignage par dessus la carte, on peut afficher ces zones inondées.
Concernant cette partie de l’application, nous avons dû nous adapter car la quantité de données comparables dans un fichier APK était limitée. Dans le but de fluidifier la navigation sur les cartes, nous avons choisi de réduire la quantité de points récupérés sur le site de la Nasa en limitant l’affichage des zones inondées à la France métropolitaine et en réduisant la résolution de leurs bords.
3. Résultats
Notre projet s’est concrétisé par le développement d’une application mobile éducative et ludique pour la sensibilisation au recul du trait de côte. Le prototype est une plateforme fonctionnelle, construite à l’aide de React Native/Expo et intégrant l’API Google Maps pour la visualisation des zones inondables.
L’architecture logicielle repose sur des fichiers JSON qui contiennent à la fois la banque des 365 défis de culture générale et la logique complexe du jeu de simulation. Ce choix permet de dissocier le contenu du code, facilitant la mise à jour et l’évolution des scénarios par un administrateur non-développeur.
Un compromis technique majeur concerne la partie Cartes d’Élévation : pour garantir la fluidité de l’application et maîtriser la taille du fichier d’installation (APK), nous avons dû réduire la résolution des données géographiques et limiter l’affichage des zones inondées à la France métropolitaine.
Démonstration :
Figure 7: Vidéo Démonstration Cailloux
4. Perspectives
L’expérience utilisateur et l’impact de notre application peuvent encore être considérablement renforcés. Nous avons, ci-dessus, identifié et exploré plusieurs pistes d’amélioration.
Tout d’abord, une évolution significative consisterait à transformer le jeu de simulation en un d’atelier collaboratif. L’idée serait de permettre à plusieurs utilisateurs d’incarner simultanément différentes parties prenantes (élu, citoyen, scientifique…) afin de prendre des décisions complexes de manière collective. Le mode collaboratif ancrerait la simulation dans la réalité de la gouvernance locale, ce qui en ferait un support utile pour les réunions de sensibilisation avec les vrais acteurs du territoire.
Parallèlement, la logique du jeu de simulation doit être affinée pour mieux représenter les dilemmes de l’action publique. Actuellement limitée à la victoire ou à la défaite (selon le budget et la satisfaction), nous souhaiterions introduire une troisième issue : le succès environnemental à long terme malgré un échec électoral à court terme. Cette nuance se déclencherait si le maire favorise la protection de l’environnement par des mesures impopulaires, subissant une défaite électorale mais sauvant le littoral. Cela permettrait de sensibiliser à la tension entre l’urgence politique et la nécessité écologique.
Ensuite, nous pensons pertinent de créer de nouveaux niveaux pour le jeu de simulation, se déroulant dans des lieux géographiques distincts afin de montrer que le recul du trait de côte affecte une diversité de milieux (littoral rocheux, estuaire, zones de marais) et non uniquement le front de mer touristique.
De plus, les défis quotidiens pourraient évoluer pour inclure de la science participative. L’application inviterait les utilisateurs à des actions concrètes sur le terrain (relevés, photos, observations) qui enrichiraient des bases de données réelles, transformant la routine ludique en un engagement civique et scientifique direct.
Enfin, nous devrons compléter les données des cartes d’élévation pour, si la performance de l’application le permet, intégrer des résolutions plus fines et étendre la couverture géographique au-delà de la France métropolitaine, offrant ainsi une visualisation encore plus complète des infrastructures menacées.
L’ensemble de ces pistes d’amélioration représente notre feuille de route pour faire évoluer l’application vers un outil encore plus complet, à la fois plus puissant, plus réaliste et plus engageant pour l’avenir de la protection du littoral.
