From 264271615cf31039c48f7d61bb9c769a42e43d57 Mon Sep 17 00:00:00 2001
From: Amadou <info@modji.ca>
Date: Wed, 19 Aug 2026 09:44:56 -0400
Subject: [PATCH] vault backup: 2026-08-19 09:44:56

---
 ...19 - Gouvernance sur les app vibe coded.md | 537 ++++++++++++++++++
 20 Work/Journal/2026/2026-08-19.md            |  75 +++
 2 files changed, 612 insertions(+)
 create mode 100644 20 Work/Ideas/2026/2026-08-19 - Gouvernance sur les app vibe coded.md
 create mode 100644 20 Work/Journal/2026/2026-08-19.md

diff --git a/20 Work/Ideas/2026/2026-08-19 - Gouvernance sur les app vibe coded.md b/20 Work/Ideas/2026/2026-08-19 - Gouvernance sur les app vibe coded.md
new file mode 100644
index 0000000..6bd87cf
--- /dev/null
+++ b/20 Work/Ideas/2026/2026-08-19 - Gouvernance sur les app vibe coded.md	
@@ -0,0 +1,537 @@
+---
+date: 2026-08-19
+status: idea
+owner: Amadou
+project:
+strategic_area:
+effort:
+impact:
+---
+
+
+> 💡 **Idea** · 🔎 **Exploring** · 🟢 **Approved** · ⏸️ **Parked** · ⚫ **Dropped** · 🚀 **Converted**
+
+# Gouvernance des applications développées par IA / Vibe Coding
+
+## TL;DR
+
+En une semaine, deux projets développés rapidement à l'aide d'outils de vibe coding ont été portés à mon attention avec une intention potentielle de mise en production :
+
+- une application facilitant la procédure de notation des appels d'offres, incluant un CMS;
+    
+- une application de gestion de projets et d'employés visant potentiellement à remplacer Vimbiz.
+    
+
+L'objectif n'est pas de freiner ce type d'initiative. Ces outils permettent aux équipes de prototyper rapidement des solutions intéressantes.
+
+Par contre, **un prototype fonctionnel n'est pas automatiquement une application prête pour la production**.
+
+Nous devrions définir un processus organisationnel permettant de valider, sécuriser, tester, documenter et gouverner ces applications avant leur utilisation officielle.
+
+---
+
+## Objectif de la discussion
+
+S'entendre avec le CTO et le responsable Infrastructure/Sécurité sur :
+
+1. les critères permettant de déterminer qu'une application doit passer par une validation TI;
+    
+2. les validations nécessaires avant une mise en production;
+    
+3. les responsabilités respectives de nos équipes;
+    
+4. les exigences minimales de sécurité, QA, architecture et gouvernance;
+    
+5. le processus permettant de faire passer un prototype à une application officiellement supportée.
+    
+
+---
+
+# Constat
+
+Le développement assisté par IA réduit considérablement la barrière technique nécessaire pour créer une application.
+
+Une personne peut maintenant produire rapidement :
+
+- une interface;
+    
+- un backend;
+    
+- une base de données;
+    
+- un système d'authentification;
+    
+- un CMS;
+    
+- des automatisations;
+    
+- des intégrations avec d'autres systèmes.
+    
+
+Cela permet beaucoup d'innovation.
+
+Cependant, la facilité de création ne garantit pas :
+
+- la sécurité;
+    
+- la qualité du code;
+    
+- la protection des données;
+    
+- la conformité;
+    
+- la maintenabilité;
+    
+- la disponibilité;
+    
+- la capacité de récupération;
+    
+- la qualité des tests;
+    
+- la documentation;
+    
+- la pérennité de la solution.
+    
+
+Le risque apparaît particulièrement lorsqu'un prototype devient progressivement un outil utilisé dans les opérations de l'organisation.
+
+---
+
+# Principe proposé
+
+> **Toute application destinée à être utilisée officiellement par l'organisation ou à traiter des données organisationnelles doit passer par un processus de validation avant sa mise en production.**
+
+Le niveau de validation devrait être proportionnel au risque.
+
+Un petit outil interne sans données sensibles ne devrait pas nécessairement suivre le même processus qu'une application qui gère des employés ou remplace un système organisationnel.
+
+---
+
+# Questions à trancher ensemble
+
+## 1. Quand une application devient-elle un projet TI?
+
+Définir les déclencheurs.
+
+Par exemple :
+
+- utilisée par plusieurs employés;
+    
+- traite ou conserve des données organisationnelles;
+    
+- contient des données personnelles ou confidentielles;
+    
+- nécessite une authentification;
+    
+- communique avec nos systèmes;
+    
+- utilise des API ou des comptes de service;
+    
+- automatise un processus d'affaires;
+    
+- remplace un outil existant;
+    
+- devient nécessaire aux opérations;
+    
+- doit être hébergée ou supportée par l'organisation.
+    
+
+À partir de quel moment une expérimentation doit-elle être déclarée?
+
+---
+
+## 2. Processus proposé
+
+### Étape 1 — Prototype / expérimentation
+
+🟢 Libre dans un environnement contrôlé.
+
+Objectif : permettre l'innovation sans créer trop de bureaucratie.
+
+Pas de données sensibles ou de production sans autorisation.
+
+### Étape 2 — Demande de mise en production
+
+Le propriétaire présente minimalement :
+
+- objectif;
+    
+- utilisateurs;
+    
+- données utilisées;
+    
+- architecture;
+    
+- technologies;
+    
+- hébergement;
+    
+- authentification;
+    
+- intégrations;
+    
+- dépendances externes;
+    
+- personne responsable;
+    
+- criticité du processus.
+    
+
+### Étape 3 — Revue
+
+Selon le type d'application :
+
+**Mon équipe**
+
+- revue fonctionnelle;
+    
+- QA;
+    
+- tests;
+    
+- accessibilité lorsque nécessaire;
+    
+- intégration avec les produits et données existants;
+    
+- documentation minimale;
+    
+- maintenabilité.
+    
+
+**Infrastructure / Sécurité**
+
+- sécurité;
+    
+- hébergement;
+    
+- authentification et autorisations;
+    
+- secrets;
+    
+- accès réseau;
+    
+- sauvegardes;
+    
+- journalisation;
+    
+- vulnérabilités;
+    
+- dépendances;
+    
+- gestion des accès.
+    
+
+**Architecture / CTO**
+
+- pertinence de la solution;
+    
+- duplication d'un système existant;
+    
+- dette technique;
+    
+- architecture;
+    
+- support à long terme;
+    
+- décision build vs buy;
+    
+- responsabilité organisationnelle.
+    
+
+### Étape 4 — Décision
+
+🟢 **Approved for production**
+
+🟡 **Approved with conditions**
+
+🟠 **Prototype only**
+
+🔴 **Not approved**
+
+---
+
+# Validation QA
+
+Une application générée avec l'aide de l'IA doit être considérée comme du logiciel à part entière.
+
+Avant une mise en production, selon sa criticité :
+
+- tests fonctionnels;
+    
+- scénarios d'erreur;
+    
+- validation des permissions;
+    
+- validation des données;
+    
+- tests de régression;
+    
+- tests sur différents profils utilisateurs;
+    
+- accessibilité lorsque pertinente;
+    
+- validation des intégrations.
+    
+
+Le fait que l'application « fonctionne » lors d'une démonstration ne constitue pas une validation suffisante.
+
+---
+
+# Sécurité
+
+Points à définir avec Infrastructure/Sécurité :
+
+- Où le code peut-il être hébergé?
+    
+- Quels services IA sont autorisés?
+    
+- Quel code ou quelles données peuvent être envoyés à un fournisseur IA?
+    
+- Comment gérer les secrets et clés API?
+    
+- Quelles méthodes d'authentification sont acceptées?
+    
+- Peut-on créer des comptes utilisateurs locaux?
+    
+- Comment gérer les permissions?
+    
+- Quels fournisseurs cloud sont autorisés?
+    
+- Quelles dépendances externes sont acceptables?
+    
+- Quels scans de vulnérabilités sont requis?
+    
+- Quels logs doivent être conservés?
+    
+- Quelles sauvegardes sont nécessaires?
+    
+- Quel processus appliquer lorsqu'une vulnérabilité est découverte?
+    
+
+---
+
+# Gouvernance des données
+
+Une application peut devenir une nouvelle source de données organisationnelles sans que nous nous en rendions compte.
+
+Pour chaque application, déterminer :
+
+- quelles données sont créées;
+    
+- quelles données sont collectées;
+    
+- où elles sont stockées;
+    
+- qui en est propriétaire;
+    
+- qui peut y accéder;
+    
+- combien de temps elles sont conservées;
+    
+- si elles contiennent des informations personnelles ou confidentielles;
+    
+- si une source officielle existe déjà;
+    
+- comment les données peuvent être exportées;
+    
+- ce qui arrive aux données si l'application est abandonnée.
+    
+
+Éviter de créer de nouvelles sources de vérité parallèles.
+
+---
+
+# Maintenabilité
+
+Question essentielle :
+
+> **Qui maintient l'application dans deux ans?**
+
+Avant approbation :
+
+- propriétaire fonctionnel identifié;
+    
+- propriétaire technique identifié;
+    
+- dépôt de code appartenant à l'organisation;
+    
+- documentation minimale;
+    
+- procédure de déploiement;
+    
+- sauvegardes;
+    
+- gestion des dépendances;
+    
+- monitoring;
+    
+- procédure en cas d'incident;
+    
+- plan de continuité si le créateur quitte l'organisation.
+    
+
+Une application ne devrait pas dépendre uniquement de la personne qui l'a créée.
+
+---
+
+# Cas 1 — Application de notation des appels d'offres
+
+Application avec CMS permettant de faciliter le processus de notation.
+
+Points à examiner :
+
+- données conservées;
+    
+- confidentialité des soumissions;
+    
+- utilisateurs et permissions;
+    
+- intégrité des notes;
+    
+- historique des modifications;
+    
+- auditabilité;
+    
+- sauvegarde;
+    
+- export des résultats;
+    
+- propriétaire du processus;
+    
+- durée de conservation;
+    
+- hébergement;
+    
+- support.
+    
+
+Question importante :
+
+> Devons-nous pouvoir démontrer ultérieurement qui a donné quelle note, quand, et si cette note a été modifiée?
+
+---
+
+# Cas 2 — Remplacement potentiel de Vimbiz
+
+Application de gestion de projets et d'employés.
+
+Ce cas présente un niveau de risque beaucoup plus élevé.
+
+À examiner notamment :
+
+- nature des données employés;
+    
+- permissions;
+    
+- rôles;
+    
+- historique;
+    
+- intégrité des données;
+    
+- sauvegardes;
+    
+- disponibilité;
+    
+- sécurité;
+    
+- confidentialité;
+    
+- export et récupération;
+    
+- intégrations;
+    
+- migration depuis Vimbiz;
+    
+- responsabilité du support;
+    
+- continuité;
+    
+- coût réel de maintenance.
+    
+
+Avant même une revue technique, une question doit être posée :
+
+> **Avons-nous réellement pris la décision organisationnelle de remplacer Vimbiz?**
+
+Le développement d'un prototype ne devrait pas, à lui seul, entraîner implicitement cette décision.
+
+---
+
+# Classification du risque
+
+Je proposerais un modèle simple.
+
+### 🟢 Faible
+
+Prototype, données non sensibles, peu d'utilisateurs, aucun processus critique.
+
+Validation légère.
+
+### 🟡 Modéré
+
+Application interne, plusieurs utilisateurs, données organisationnelles ou intégrations.
+
+QA + revue technique + sécurité.
+
+### 🔴 Élevé
+
+Données personnelles/confidentielles, employés, finance, processus critique, authentification importante ou remplacement d'un système officiel.
+
+Revue complète et approbation formelle avant production.
+
+---
+
+# Point important : ne pas tuer l'innovation
+
+Le processus doit rester suffisamment léger pour que les employés continuent à expérimenter.
+
+L'objectif devrait être :
+
+> **Expérimenter facilement. Mettre en production de façon contrôlée.**
+
+Nous voulons éviter deux extrêmes :
+
+- interdire ou ralentir inutilement les prototypes;
+    
+- laisser des prototypes devenir des systèmes de production sans gouvernance.
+    
+
+---
+
+# Questions à poser au CTO et Infrastructure/Sécurité
+
+- Sommes-nous d'accord qu'il faut formaliser ce processus maintenant?
+    
+- Quels types d'applications nécessitent obligatoirement une revue?
+    
+- Qui peut autoriser une mise en production?
+    
+- Quelles responsabilités appartiennent à mon équipe?
+    
+- Quelles responsabilités appartiennent à Infrastructure/Sécurité?
+    
+- Devons-nous définir une liste d'outils IA autorisés?
+    
+- Quelles exigences minimales de sécurité voulons-nous imposer?
+    
+- Quel niveau de QA voulons-nous selon la criticité?
+    
+- Où doivent vivre le code et la documentation?
+    
+- Qui devient propriétaire d'une application après son approbation?
+    
+- Devons-nous tenir un registre des applications internes développées de cette façon?
+    
+
+---
+
+# Proposition de prochaine étape
+
+Ne pas commencer par une politique lourde.
+
+Utiliser les deux projets actuels comme cas concrets pour définir un premier processus :
+
+**Prototype → Évaluation du risque → Revue → QA/Sécurité → Approbation → Production → Gouvernance**
+
+Puis documenter une version simple du processus à appliquer aux prochains projets.
\ No newline at end of file
diff --git a/20 Work/Journal/2026/2026-08-19.md b/20 Work/Journal/2026/2026-08-19.md
new file mode 100644
index 0000000..1a93a2d
--- /dev/null
+++ b/20 Work/Journal/2026/2026-08-19.md	
@@ -0,0 +1,75 @@
+
+# Wednesday, August 19th 2026
+
+← [[2026-08-18]] | **Week 34** | [[2026-08-20]] →
+
+---
+
+## Meetings
+
+- Sharon qui me parle du projet de Jerry qu'il a fait entièrement de son coté. Je lui ai conseillé de parler à Marc sur l'impact négative sur l'équipe. A savoir que Jerry donne des idées qui ne sont pas tjrs réalisable. De plus, tout son concept ne doit être vu que comme un POC car ce ne fut jamais accepté. 
+
+---
+
+## Significant Events
+
+-  
+
+---
+
+## Decisions Made
+
+```dataview
+LIST
+FROM "20 Work/Decisions"
+WHERE startswith(file.name, this.file.name + " - ")
+SORT file.name ASC
+```
+- [[]]
+
+---
+
+## People / Management
+
+Feedback given, coaching moments, observations.
+
+- 
+
+---
+
+## Projects
+
+Important project changes only.
+
+- 
+
+---
+
+## Leadership Reflection
+
+### What surprised me today?
+
+- 
+
+### What did I learn today?
+
+- 
+
+### What would I do differently next time?
+
+- 
+
+---
+
+## Follow-ups
+
+> Only actions that still belong to me.
+> Everything else should already be in **Twos**, **Jira**, or **Monday**.
+
+- [ ]
+
+---
+
+## Related
+
+- [[]]
\ No newline at end of file