vault backup: 2026-08-19 09:44:56

2026-08-19 09:44:56 -04:00
parent 1b05737f1c
commit 264271615c
2 changed files with 612 additions and 0 deletions
@@ -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.