Temporary unstable
Temporary unstable
Conformité dans le vibe coding et le développement logiciel assisté par l’IA
Le vibe coding permet aujourd’hui à une seule personne de développer des logiciels qui auraient autrefois nécessité une petite équipe. Grâce aux outils d’IA, un freelance peut créer un prototype, construire des interfaces, rédiger de la documentation, générer des tests, détecter des erreurs et, dans certains cas, produire très rapidement une application pleinement fonctionnelle.
Cela ne change toutefois rien à la responsabilité liée au produit final.
Lorsqu’on publie un programme Windows, une application Android, une application web ou un outil fondé sur l’IA, la question n’est pas seulement : Le logiciel fonctionne-t-il ?
Il faut aussi se demander : Est-ce que je sais ce que fait le logiciel, pourquoi il le fait, quelles données il traite, quels composants il utilise, quels risques existent et puis-je démontrer que j’ai développé le produit de manière responsable ?
La conformité ne signifie pas nécessairement une bureaucratie considérable. Pour un freelance ou un développeur indépendant, il s’agit surtout d’établir une pratique de développement proportionnée et documentée.
L’IA peut écrire du code. Elle ne doit pas prendre en charge la responsabilité du développeur.
1. Conformité juridique
Un logiciel n’existe pas en dehors du droit. Les règles applicables dépendent notamment du produit, de ses utilisateurs, du marché et des données traitées. Une application d’apprentissage linguistique sans inscription présente, par exemple, un profil de risque très différent d’un système traitant des données clients, des courriels, des données de santé ou des informations concernant des enfants.
☐ Ai-je décrit ce que fait réellement le produit ?
☐ Ai-je identifié les utilisateurs ?
☐ Ai-je identifié les pays dans lesquels le produit est proposé ?
☐ Ai-je évalué si le RGPD s’applique ?
☐ Est-ce que je sais quelles données à caractère personnel sont traitées ?
☐ Ai-je une base juridique pour leur traitement ?
☐ Ai-je documenté la finalité du traitement ?
☐ Est-ce que je collecte uniquement les données nécessaires ?
☐ L’utilisateur peut-il faire supprimer ses données lorsque cela est requis ?
☐ Ai-je défini une durée de conservation ?
☐ Est-ce que je sais où les données sont traitées ?
☐ Est-ce que j’utilise des sous-traitants ou des services cloud ?
☐ Les accords de traitement des données nécessaires sont-ils en place ?
☐ Le produit dispose-t-il d’une politique de confidentialité appropriée ?
☐ Utilise-t-il des cookies, des outils d’analyse ou du suivi ?
☐ Des règles concernant les enfants sont-elles applicables ?
☐ Le droit de la consommation est-il applicable ?
☐ Des exigences d’accessibilité sont-elles applicables ?
☐ La réglementation européenne sur l’IA est-elle pertinente ?
☐ Ai-je identifié les domaines nécessitant un conseil juridique professionnel ?
2. Vie privée et protection des données
La protection de la vie privée doit faire partie de la conception. Une approche utile consiste à appliquer la protection des données dès la conception et la minimisation des données : si le logiciel n’a pas besoin d’une information, il faut envisager de ne pas la collecter. Pour un développeur indépendant, moins de données sensibles signifie aussi moins de risques et de contraintes de sécurité.
☐ Ai-je établi l’inventaire des données collectées ?
☐ Est-ce que je sais pourquoi chaque type de données est nécessaire ?
☐ Certaines collectes peuvent-elles être supprimées ?
☐ Les données peuvent-elles être traitées localement plutôt que dans le cloud ?
☐ L’utilisateur sait-il quelles informations sont collectées ?
☐ Sait-il pourquoi elles sont collectées ?
☐ Sait-il si elles sont transmises à des tiers ?
☐ Le logiciel transmet-il des données à des services d’IA ?
☐ Ai-je examiné la manière dont le fournisseur d’IA traite les données ?
☐ Les journaux contiennent-ils des données personnelles ?
☐ Peuvent-ils être anonymisés ?
☐ Ai-je défini les durées de conservation ?
☐ Les données peuvent-elles être supprimées ?
☐ Les données pertinentes peuvent-elles être exportées ?
☐ Les sauvegardes sont-elles incluses dans la politique de suppression ?
☐ Les données de test sont-elles exemptes de données personnelles inutiles ?
☐ Est-ce que j’évite d’utiliser des données de production en développement ?
☐ Les paramètres de confidentialité sont-ils compréhensibles ?
☐ Ai-je documenté les flux de données ?
☐ Ai-je effectué une revue de la confidentialité avant la mise en production ?
3. Conformité logicielle et sécurité
L’IA peut produire du code fonctionnel contenant néanmoins des vulnérabilités, notamment dans l’authentification, les fichiers, les bases de données, les API, les communications réseau et les entrées utilisateur. Le code généré par IA doit donc être compris, relu et testé.
☐ Les clés API sont-elles conservées hors du code source ?
☐ Les mots de passe et jetons sont-ils protégés ?
☐ Les fichiers .env et similaires sont-ils exclus de Git ?
☐ Ai-je vérifié le dépôt pour détecter d’anciens secrets ?
☐ Les entrées utilisateur sont-elles validées ?
☐ Les téléversements de fichiers sont-ils limités et contrôlés ?
☐ Les connexions sont-elles sécurisées ?
☐ L’authentification est-elle correctement mise en œuvre ?
☐ L’autorisation est-elle distincte de l’authentification ?
☐ Les utilisateurs disposent-ils uniquement des droits nécessaires ?
☐ Les erreurs sont-elles gérées sans divulguer d’informations sensibles ?
☐ Les journaux contiennent-ils des mots de passe, jetons ou secrets ?
☐ La base de données est-elle protégée ?
☐ Existe-t-il une sauvegarde lorsque cela est nécessaire ?
☐ La restauration a-t-elle été testée ?
☐ Les dépendances sont-elles à jour ?
☐ Sont-elles analysées pour détecter les vulnérabilités connues ?
☐ Les fonctions de débogage ont-elles été retirées de la production ?
☐ Ai-je effectué une revue de sécurité avant la publication ?
☐ Est-ce que je sais quoi faire si une vulnérabilité est découverte ?
4. Dépendances, open source et licences
Un logiciel se compose rarement uniquement de son propre code. Même un petit projet peut utiliser des bibliothèques, frameworks, polices, images, icônes, bases de données, API et services d’IA. Le vibe coding peut rendre ces choix moins transparents lorsqu’un assistant installe rapidement une dépendance sans évaluation explicite.
☐ Ai-je une liste des principales dépendances ?
☐ Est-ce que je sais pourquoi chacune est utilisée ?
☐ Les dépendances inutiles ont-elles été supprimées ?
☐ Est-ce que je connais leurs licences ?
☐ Leur utilisation commerciale est-elle autorisée ?
☐ Certaines licences imposent-elles une attribution ?
☐ Certaines imposent-elles la publication du code source ?
☐ Ai-je documenté les composants tiers ?
☐ Est-ce que je connais l’origine des images ?
☐ Est-ce que je connais l’origine des icônes ?
☐ Est-ce que je connais l’origine des polices ?
☐ Ai-je les droits nécessaires sur les données de test ?
☐ Ai-je les droits nécessaires sur les textes d’entraînement ou d’exemple ?
☐ Ai-je examiné les conditions des API externes ?
☐ Ai-je examiné les conditions des services d’IA ?
☐ Les numéros de version sont-ils enregistrés ?
☐ Les dépendances du projet peuvent-elles être reproduites ?
☐ Ai-je vérifié les vulnérabilités connues ?
☐ Les composants problématiques peuvent-ils être remplacés ?
☐ Puis-je expliquer les principaux composants tiers dont dépend le produit ?
5. Un processus de développement documenté
C’est une différence essentielle entre le vibe coding expérimental et le développement professionnel assisté par IA. Commencer par un prototype n’est pas un problème. Le problème apparaît lorsqu’il devient un logiciel de production sans transition vers un développement contrôlé.
☐ Le but du produit est-il décrit ?
☐ Les exigences fonctionnelles sont-elles documentées ?
☐ Les exigences non fonctionnelles sont-elles documentées ?
☐ Le périmètre du projet est-il défini ?
☐ L’architecture est-elle documentée ?
☐ Les décisions de conception importantes sont-elles documentées ?
☐ Un système de gestion de versions est-il utilisé ?
☐ Les commits sont-ils explicites ?
☐ Des branches sont-elles utilisées lorsque c’est pertinent ?
☐ Une ancienne version peut-elle être recréée ?
☐ Des numéros de version sont-ils utilisés ?
☐ Des notes de version ou un changelog sont-ils tenus à jour ?
☐ Les changements importants sont-ils documentés ?
☐ Les limitations connues sont-elles documentées ?
☐ Les bugs importants sont-ils enregistrés ?
☐ La documentation évolue-t-elle avec le code ?
☐ Le processus de build est-il documenté ?
☐ Le projet peut-il être construit depuis une installation propre ?
☐ Une autre personne compétente pourrait-elle comprendre la structure du projet ?
☐ Existe-t-il des critères clairs pour décider qu’une version est prête ?
6. Tests, validation et assurance qualité
Le fait qu’un programme démarre sans erreur ne signifie pas qu’il a été testé. Les tests doivent vérifier qu’il respecte les exigences et qu’il réagit correctement aux situations anormales. L’IA peut aider à produire des tests, mais la validation humaine reste importante.
☐ Existe-t-il une stratégie de test ?
☐ Les fonctions critiques ont-elles été testées ?
☐ Des tests unitaires sont-ils utilisés lorsque c’est pertinent ?
☐ Des tests d’intégration sont-ils utilisés lorsque c’est pertinent ?
☐ Les parcours utilisateur ont-ils été testés ?
☐ Les entrées invalides ont-elles été testées ?
☐ Les valeurs vides ont-elles été testées ?
☐ Les valeurs limites ont-elles été testées ?
☐ Les scénarios d’échec ont-ils été testés ?
☐ La perte de connexion Internet a-t-elle été testée si nécessaire ?
☐ L’absence de fichiers ou ressources a-t-elle été testée ?
☐ Les autorisations ont-elles été testées ?
☐ L’installation a-t-elle été testée ?
☐ La mise à niveau depuis une version antérieure a-t-elle été testée ?
☐ La désinstallation a-t-elle été testée si nécessaire ?
☐ Les appareils ou tailles d’écran pertinents ont-ils été testés ?
☐ Des tests de régression ont-ils suivi les changements importants ?
☐ Les résultats des tests sont-ils documentés ?
☐ Les défauts critiques ont-ils été corrigés avant la publication ?
☐ La version finale empaquetée a-t-elle été testée ?
7. L’IA comme outil de développement
Il faut distinguer un logiciel développé avec l’aide de l’IA d’un logiciel qui utilise lui-même l’IA. L’utilisation de Codex ou d’un autre outil pour écrire du code ne transforme pas automatiquement le produit final en système d’IA. Cette utilisation doit néanmoins être gérée professionnellement.
☐ Est-ce que je sais quels outils d’IA sont utilisés ?
☐ Est-ce que je sais quelles étapes ils assistent ?
☐ Est-ce que j’envoie des informations confidentielles à l’IA ?
☐ Est-ce que j’envoie des données personnelles à l’IA ?
☐ Est-ce que j’envoie du code source ou des documents clients à l’IA ?
☐ Ai-je le droit de le faire ?
☐ Le code généré par IA est-il relu ?
☐ Est-il testé ?
☐ Les dépendances proposées par l’IA sont-elles vérifiées ?
☐ Les API et fonctions proposées sont-elles vérifiées ?
☐ Le code critique pour la sécurité est-il examiné séparément ?
☐ Les refactorisations importantes sont-elles approuvées après revue ?
☐ Puis-je expliquer les fonctions centrales sans dépendre de l’IA ?
☐ Les décisions d’architecture importantes sont-elles documentées ?
☐ La documentation générée par IA est-elle vérifiée ?
☐ Les affirmations juridiques générées par IA sont-elles vérifiées séparément ?
☐ Les faits sont-ils vérifiés et pas seulement bien formulés ?
☐ Une approbation humaine est-elle nécessaire avant publication ?
☐ Le projet peut-il continuer sans la session d’IA particulière ?
☐ Est-il clair que la responsabilité reste celle du développeur ?
8. Lorsque l’IA fait partie du produit
Si le produit utilise lui-même un modèle de langage, d’image, de classification ou une autre IA, des questions supplémentaires apparaissent. L’utilisateur doit pouvoir comprendre quand l’IA intervient, à quoi elle sert et quelles sont ses limites importantes.
☐ L’utilisation de l’IA dans le produit est-elle documentée ?
☐ L’utilisateur sait-il quand l’IA influence significativement le résultat ?
☐ La fonction de l’IA est-elle clairement décrite ?
☐ Le fournisseur du modèle est-il connu ?
☐ Les versions pertinentes sont-elles enregistrées ?
☐ Est-ce que je sais quelles données sont envoyées au modèle ?
☐ Les données personnelles sont-elles protégées ?
☐ Les informations sensibles peuvent-elles être évitées ?
☐ Le risque d’hallucination a-t-il été évalué ?
☐ Les résultats importants de l’IA sont-ils validés ?
☐ Existe-t-il une supervision humaine lorsque les conséquences l’exigent ?
☐ L’utilisateur peut-il corriger ou remplacer un résultat de l’IA ?
☐ Les décisions automatisées ont-elles été identifiées ?
☐ Les risques de biais ou de discrimination ont-ils été évalués ?
☐ Les scénarios d’abus ont-ils été envisagés ?
☐ Les limites pertinentes sont-elles communiquées ?
☐ La pertinence de l’AI Act a-t-elle été évaluée ?
☐ La classification de risque a-t-elle été examinée si nécessaire ?
☐ La fonction d’IA peut-elle être désactivée si nécessaire ?
☐ Existe-t-il une procédure pour les résultats erronés ou préjudiciables ?
9. L’éthique au-delà de la conformité
Un logiciel légal n’est pas nécessairement un bon logiciel. La conformité fixe souvent des exigences minimales. L’éthique pose une autre question : Devons-nous le faire simplement parce que nous pouvons le faire ? Cette question est particulièrement importante pour l’IA, la surveillance, l’analyse comportementale, les enfants, la personnalisation et la collecte massive de données.
☐ Le produit résout-il un problème réel ?
☐ Son objectif véritable est-il clair pour l’utilisateur ?
☐ Est-ce que je collecte des informations uniquement parce que c’est techniquement possible ?
☐ La conception respecte-t-elle la vie privée ?
☐ Les choix de l’utilisateur sont-ils réellement volontaires ?
☐ Est-ce que j’évite les dark patterns manipulateurs ?
☐ Est-il facile de dire non ?
☐ Est-il facile de changer d’avis ?
☐ L’utilisateur comprend-il les conséquences de ses choix ?
☐ Des enfants ou personnes vulnérables sont-ils concernés ?
☐ Le produit pourrait-il servir à la surveillance ?
☐ Pourrait-il être détourné ?
☐ Ai-je envisagé les conséquences imprévues ?
☐ Certains groupes pourraient-ils être défavorisés par les algorithmes ?
☐ Les évaluations automatisées sont-elles équitables ?
☐ Est-ce que je présente l’IA comme plus fiable qu’elle ne l’est ?
☐ L’utilisateur peut-il distinguer les faits des évaluations générées par IA ?
☐ Le produit respecte-t-il l’autonomie de l’utilisateur ?
☐ Accepterais-je personnellement le même traitement de données ?
☐ Pourrais-je expliquer et défendre publiquement les choix fondamentaux du produit ?
La transparence ne signifie pas publier tout le code source. Elle signifie ne pas cacher à l’utilisateur les éléments importants : collecte de données, utilisation de l’IA, services externes ou limitations significatives.
☐ Le développeur ou l’entreprise est-il identifiable ?
☐ Des coordonnées sont-elles disponibles ?
☐ Le but du produit est-il décrit ?
☐ Ses fonctions principales sont-elles décrites correctement ?
☐ Le marketing évite-t-il les affirmations exagérées ?
☐ Les limitations importantes sont-elles décrites ?
☐ L’utilisation de l’IA est-elle indiquée lorsque c’est pertinent ?
☐ La collecte de données est-elle expliquée ?
☐ Le traitement par des tiers est-il expliqué ?
☐ Les droits des utilisateurs sont-ils compréhensibles ?
☐ Un numéro de version est-il disponible ?
☐ Un historique des changements existe-t-il lorsque c’est pertinent ?
☐ Les problèmes graves connus sont-ils documentés ?
☐ L’utilisateur peut-il signaler une erreur ?
☐ Peut-il poser des questions sur la confidentialité ?
☐ Peut-il identifier le contenu généré par IA lorsque cela est nécessaire ?
☐ Les décisions automatisées sont-elles expliquées lorsque cela est requis ?
☐ La documentation est-elle rédigée dans un langage compréhensible ?
☐ Les affirmations techniques et juridiques sont-elles exactes ?
☐ Puis-je étayer les principales affirmations concernant le produit ?
Un développeur indépendant ne peut pas reproduire l’organisation de conformité d’une grande entreprise, et ce n’est pas l’objectif. La conformité doit être proportionnée au risque. Un outil local sans accès Internet ni données personnelles nécessite normalement moins de gouvernance qu’un service cloud traitant de grandes quantités de données personnelles.
☐ Ai-je classé le niveau de risque du projet ?
☐ Est-ce que je sais quels domaines je peux gérer moi-même ?
☐ Est-ce que je sais quand une expertise externe est nécessaire ?
☐ Ai-je séparé prototype et version de production ?
☐ Ai-je une sauvegarde du projet ?
☐ Le dépôt est-il sécurisé ?
☐ L’accès aux systèmes de développement est-il protégé ?
☐ Les données clients sont-elles séparées des données de test ?
☐ Ai-je une procédure simple de publication ?
☐ Ai-je une checklist de test avant publication ?
☐ Ai-je une checklist de sécurité ?
☐ Ai-je une checklist de confidentialité ?
☐ Ai-je une checklist de licences ?
☐ Ai-je documenté les principaux outils d’IA ?
☐ Ai-je une vue d’ensemble des abonnements et services externes nécessaires ?
☐ Est-ce que je sais ce qui arrive aux utilisateurs si j’arrête le produit ?
☐ Les données peuvent-elles être exportées ou transférées si nécessaire ?
☐ Ai-je une procédure pour les défauts graves ?
☐ Ai-je une procédure pour les incidents de sécurité ?
☐ Puis-je documenter pourquoi j’ai jugé le produit suffisamment sûr et responsable pour le publier ?
Un petit projet n’a pas besoin d’un système qualité de mille pages. Une solution pratique consiste à créer un répertoire /docs contenant par exemple README.md, REQUIREMENTS.md, ARCHITECTURE.md, DATA-FLOW.md, PRIVACY.md, SECURITY.md, DEPENDENCIES.md, AI-USAGE.md, TESTING.md, RELEASE-CHECKLIST.md et CHANGELOG.md.
Dix documents courts et maintenus valent mieux qu’un système de conformité de 200 pages que personne ne met à jour.
☐ Les exigences de cette version sont définies.
☐ Le bon code a été commité.
☐ Le dépôt est propre.
☐ La bonne version est identifiée ou taguée.
☐ Le projet peut être construit de manière reproductible.
☐ Les tests automatisés réussissent.
☐ Les parcours utilisateur critiques ont été testés manuellement.
☐ L’installeur, l’APK ou le package final a été testé.
☐ Les bugs critiques connus sont résolus.
☐ Les dépendances ont été vérifiées.
☐ Les licences ont été vérifiées.
☐ Les secrets ont été vérifiés.
☐ La sécurité a été revue.
☐ La confidentialité a été revue.
☐ Les fonctions d’IA ont été revues.
☐ Les risques éthiques ont été évalués.
☐ La documentation correspond à la version réelle.
☐ Le changelog a été mis à jour.
☐ Une sauvegarde ou un retour arrière est possible.
☐ Le développeur a explicitement approuvé la publication.
Le vibe coding n’est pas nécessairement l’opposé du développement logiciel professionnel. Il peut en être le point de départ.
L’IA permet à un freelance d’expérimenter plus rapidement et de développer des logiciels qui auraient autrefois nécessité beaucoup plus de ressources. Mais précisément parce que la productivité augmente fortement, il devient nécessaire d’introduire des points de contrôle.
Idée → vibe coding → prototype → exigences → développement structuré → tests → contrôle de conformité → publication → maintenance
Il n’est pas nécessaire de documenter chaque prompt ou chaque expérience. Mais lorsqu’un prototype commence à devenir un produit, les exigences, l’architecture, la sécurité, la confidentialité, les dépendances et les tests doivent progressivement être formalisés.
L’IA peut aider dans presque toutes ces tâches : écrire des cas de test, rechercher des problèmes de sécurité, maintenir la documentation, analyser les dépendances, vérifier une publication à l’aide d’une checklist et comparer l’implémentation aux exigences.
Mais une tâche ne doit pas être déléguée : la décision que le produit est suffisamment sûr et responsable pour être publié.
Pour un freelance, l’objectif n’est donc pas de reproduire en miniature la conformité d’une grande entreprise. L’objectif est de disposer d’un processus documenté, proportionné et reproductible permettant de démontrer que le produit n’a pas simplement été généré, mais qu’il a été compris, contrôlé, testé et approuvé.
.