--- tags: ["day"] type: "day" date: "2026-03-19" priority: 10 --- # 2026-03-19 (jeudi) ## Todo [[Todo]] ## Done ## Evénements --- ### [[01_JOURNAL/2026/2026-03-19]] 09:00/10:00 [[03_PROJETS/KIT-EXO]] - DataGrandEst - Guide animateur groupe projet #event Réunion Microsoft Teams Participants: RYCKELYNCK Guillaume; Nathalie Dejour; TSCHUDY Eric Travail sur le document : https://www.datagrandest.fr/portal/dw/oeditor?docId=957e7166ac10800e406e6639062fb2cf --- ### [[01_JOURNAL/2026/2026-03-19]] 11:00/12:00 [[03_PROJETS/NPDGE]] - DN x DIMAP : Comitologie CAC - DataGrandEst #event Réunion Microsoft Teams Participants: MCDONALD Evan (SII); RYCKELYNCK Guillaume; BECKER Julien; THOMAS Philippe; HOLTZMANN Julien; VADIN Mickaël; CROISET Guillaume CAC issue des bonnes pratiques numériques (ETIL) CAC pas là pour bloquer Objectif = maitriser les incidents de production Processus obligatoire Plusieurs espaces pour simplifier le déroulé Tout changement sur un environnement de production doit être maitrisé par celui qui fait le changement. * Changement standard = Maitrise = régularité => aboutissement d’une procédure qui garantie le fonctionnement - déclaration uniquement pour la traçabilité Autre principe => intégration continue (automatisation du changement) * Changement normal = unique ou ponctuel = passage en CAC avec questionnaire sur les impacts du changement / retour arrière et communication (focus technique) Le CAC ne se prononce pas sur le besoin de faire ce changement et sa validité * Changement urgent = doit rester anecdotique et non planifié 1. Compromission cyber 2. Arrêt de production (plateforme ou fonctionnelle) 3. Décision hiérarchique Impact de la modification n’est pas pris en compte Si un changement normal a déjà été réalisé sur le même type de modification Caractérisation de la standardisation du changement se fait au niveau de la DN. Besoin de connaître la chaine de test et de mise en production et d’impact similaire. Bonne pratique = standardiser autant que possible les modifications Passage en CAC: pour les modifications en batch / en masse (via script ou API) CAC = interne DN => pas d’intervention de chefs projet DN A prévoir de façon globale : intégrer progressivement Evan dans la prise en main de la plateforme. Ex.: Visibilité dépôt Git Camptocamp et eXo --- ### [[01_JOURNAL/2026/2026-03-19]] 13:30/13:45 [[03_PROJETS/NPDGE-LOT5_CMS]] - O3296 - RDV visio DataGrandEst sur le CMS - Weekly #event #absent https://meet.google.com/vyc-cbue-euq Participants: Erine Meyer; RYCKELYNCK Guillaume; RODRIGUEZ Jean-pierre; Didier LAPEYRONNIE --- ### [[01_JOURNAL/2026/2026-03-19]] 14:00/15:00 [[03_PROJETS/NPDGE-LOT1]] - DGE - Echanges concernant la demandes de chiffrages évolutions 2026 #event https://meet.google.com/vux-ukby-gpk Participants: francois.vanderbiest@camptocamp.com; RYCKELYNCK Guillaume; laure-helene.bruneton@camptocamp.com; RODRIGUEZ Jean-pierre; florian.necas Objectif : répondre aux questions relatives aux évolutions demandées. Travail directement sur le fichier des évolutions transmis par JPR. Cf. fichier transmis à JPR, FVDB et LHB suite à la réunion. Fichier de suivi (Google) : https://docs.google.com/spreadsheets/d/1gWrbmot4EWMhZ4Ms1vvPp7pr-e34Sjxt/edit?gid=667850584#gid=667850584 --- ### [[01_JOURNAL/2026/2026-03-19]] 15:30/16:30 [[03_PROJETS/NPDGE-LOT3B]] - DataGrandEst : Chatbot - Retour par rapport aux tests #event Réunion Microsoft Teams Participants: Didier LAPEYRONNIE; RYCKELYNCK Guillaume; Franþois Mathonnet; RODRIGUEZ Jean-pierre; pierre.laulhe Retour de la phase de test: * Cibler ls attendus => périmètre fonctionnel * Attentes explicatives sur ce que doit faire le chatbot Ressenti utilisateur <=> défauts techniques Repartir du schéma de réponse proposé. Identifier les causes des problèmes indiqués. => Limiter l’intervention du chatbot Identification des pistes à investiguer: * Certaines données ne ressortent pas => pb d’indexation (ex. orthophotos sur des années) * Infos non prises en compte (ex.: indication temporelle “2024”) 2 pistes: - Travailler côté chatbot pour mieux identifier les dates - Travailler côté métadonnées * Idem sur le volet géographique : mauvaise compréhension de la géographie Faut-il intégrer des information externes (ex.: organisation administrative, sigles, etc.) * Mauvais rapprochement sémantique. Ex. : orthophotographie <=> vue aérienne * Revoir la pondération des champs * Erreur: “une erreur est intervenue” * Insuffisance sur les questions génériques “C’est quoi DataGrandEst ?”, “D’où viennent les données”, “Quelle est la fréquence de mise à jour ?” Limite: * Côté catalogue le chatbot ne travaille que sur les données du DataHub (réduire les allucinations) * Côté CMS Besoin de faire dire au chatbot quand il ne comprend pas une question => ex.: “macdo”. Consommation: * 110 jours prévu initialement * 80 jours pris sur la R&D * Total : 190 jours Support = 10 jours Besoin de disposer d’une estimation des évolutions Besoin de prioriser les problématiques Besoin d’identifier ce qui est un résultat acceptable => Vision sous forme de jauge : on est dans le rouge. Comment on passe dans le orange, puis dans le vert ? Quel sera le ROI ? !! L’IA évolue rapidement et les attentes de l’utilisateur aussi Module Phenix => comprendre comment ça fonctionne. Prévoir séance sur ce sujet ? - [x] [[03_PROJETS/NPDGE-LOT3B]] - Transmettre schéma de principe du chatbot (IappyMonday) à Pierre pour valider [date: 2026-03-19] #aborted ## Notes ---