537 lines
11 KiB
Markdown
537 lines
11 KiB
Markdown
---
|
|
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. |