Les assistants de programmation produisent aujourd’hui du code qui compile, passe les tests et ressemble à s’y méprendre à du travail humain. Coder avec l’IA est devenu une pratique courante, y compris dans les petites équipes. Pourtant, quand l’éditeur Veracode a soumis 80 tâches de programmation à plus de 100 modèles de langage en 2025, environ 45 % du code produit contenait une faille figurant au Top 10 de l’OWASP, la liste de référence des vulnérabilités web.
Pour une TPE, une PME ou un établissement de santé qui fait développer son site, son application métier ou les modules de son ERP, la question n’est donc pas de savoir si l’IA est utilisée, mais qui contrôle ce qu’elle produit et qui en assumera la maintenance. Depuis le 2 août 2026, l’AI Act impose de nouvelles obligations de transparence ; elles ne disent rien, en revanche, de la qualité du code. Voici pourquoi le contrôle humain reste indispensable, et comment l’organiser.
Coder avec l’IA : du code plausible, pas forcément correct
Un modèle de langage ne raisonne pas sur votre métier : il prédit la suite la plus vraisemblable d’un texte, à partir des milliards de lignes qu’il a observées. Le code qu’il propose est donc plausible, ce qui n’est pas la même chose que correct. Il respecte la syntaxe, suit les conventions courantes et passe souvent les premiers tests, mais rien ne garantit qu’il traduise fidèlement une règle de gestion propre à votre entreprise, comme un calcul de remise, un circuit de validation ou un délai réglementaire.
Le piège tient précisément à cette apparence de qualité. Un bug de logique métier ne se signale ni au compilateur ni à l’interface : il apparaît trois mois plus tard, en production, sur un cas limite que personne n’avait pensé à tester. La situation est d’autant plus trompeuse que l’IA génère volontiers les tests de son propre code. Ces tests valident ce que le code fait, pas ce qu’il devrait faire, et rassurent l’équipe sans rien prouver.
Des failles de sécurité bien réelles
Les modèles reproduisent ce qu’ils ont appris, et les dépôts publics regorgent de code ancien ou vulnérable : requêtes SQL construites par concaténation, algorithmes de chiffrement dépassés, dépendances abandonnées. L’étude de Veracode publiée en juillet 2025 le montre clairement. Les modèles testés échouaient à se protéger du cross-site scripting dans 86 % des cas et de l’injection dans les journaux dans 88 % des cas, et le taux d’échec dépassait 70 % pour le langage Java. Les modèles plus récents écrivent un code plus propre, sans pour autant être plus sûrs.
Un risque plus insidieux concerne les dépendances. Il arrive qu’un modèle invente le nom d’une bibliothèque qui n’existe pas ; des attaquants enregistrent alors ce nom sur les dépôts publics et y placent du code malveillant, une technique baptisée slopsquatting. Une étude présentée à USENIX Security en 2025 a relevé des taux d’hallucination de paquets allant de 5,2 % pour les modèles commerciaux à 21,7 % pour les modèles open source, et plus de 205 000 noms inventés. Une réévaluation menée sur les modèles du printemps 2026 mesure des taux nettement plus faibles, autour de 5 à 6 %, mais conclut que la menace persiste : un seul paquet fantôme installé suffit à compromettre un serveur.
La dette technique invisible
Le coût réel du code généré n’apparaît pas au moment de l’écrire, mais au moment de le modifier. Un code que personne n’a vraiment conçu est difficile à faire évoluer, car personne ne sait pourquoi telle condition existe ni ce qui casserait si on la retirait. Une équipe qui accepte des suggestions sans les comprendre accumule ainsi des zones opaques, et la première évolution un peu ambitieuse se transforme en réécriture.
Ce risque est particulièrement sensible sur les logiciels qui évoluent au rythme de leur éditeur. Un module Odoo doit être migré à chaque version majeure, une extension WordPress suivre les évolutions du cœur, une application Symfony monter de version tous les deux ans. Si le code a été produit rapidement mais sans structure ni documentation, chaque migration coûte plus cher que le gain de temps initial. La vitesse de l’IA se paie alors sur toute la durée de vie de l’application, c’est-à-dire précisément là où une PME a le moins de marge.
Il existe aussi une dette de connaissance. Lorsqu’un développeur écrit lui-même une fonctionnalité, il en garde la logique en tête et peut l’expliquer à un collègue ou à un client. Lorsqu’il assemble des blocs proposés par une IA, cette compréhension n’existe parfois nulle part. Pour une petite structure qui dépend d’un prestataire ou d’un développeur unique, c’est un risque d’organisation autant que technique : le jour où la personne change de poste, le logiciel devient une boîte noire. Exiger un code lisible, commenté et accompagné d’une documentation des choix reste la meilleure assurance contre ce scénario.
AI Act et RGPD : un plancher réglementaire, pas une garantie de qualité
L’AI Act est entré dans sa phase d’application générale le 2 août 2026. Ses obligations de transparence imposent notamment de signaler aux utilisateurs qu’ils interagissent avec une IA et de marquer certains contenus générés, tandis que les exigences les plus lourdes pour les systèmes à haut risque ont été repoussées à décembre 2027 par le règlement omnibus adopté en juillet 2026. Ces règles encadrent les systèmes d’IA eux-mêmes ; elles ne fixent aucune exigence sur la qualité du code qu’un développeur produit avec l’aide d’un assistant.
Le RGPD joue un rôle complémentaire, souvent négligé : un extrait de code envoyé à un assistant en ligne peut contenir des données clients, des identifiants ou des clés d’accès, et quitter ainsi votre maîtrise. Ces deux textes posent un plancher. Mais un code parfaitement conforme peut rester vulnérable, illisible et impossible à maintenir, et aucun règlement ne protège une entreprise d’une architecture bancale.
Les pratiques qui permettent d’en tirer parti sereinement
Utilisée avec discernement, l’IA accélère réellement le développement. Elle excelle sur le code répétitif, la documentation, la conversion d’un format vers un autre ou l’exploration d’une bibliothèque inconnue. Pour en profiter sans en subir les effets, quelques règles suffisent. Chaque suggestion se relit comme le code d’un stagiaire compétent mais sans contexte métier, avec une question simple : saurais-je le corriger s’il tombait en panne demain ? Chaque dépendance proposée se vérifie avant installation, en contrôlant qu’elle existe, qu’elle est maintenue et qu’elle provient d’un éditeur identifié, ce qui prend quelques secondes.
Les tests, enfin, doivent porter sur les cas limites et les règles métier plutôt que sur le chemin idéal, et être écrits ou au minimum relus par quelqu’un qui connaît le besoin. Une revue de code humaine avant chaque mise en production, des outils d’analyse de sécurité automatisés et une documentation des choix d’architecture complètent le dispositif. La responsabilité, elle, ne se délègue pas à un modèle : un développeur qui livre du code en assume la maintenance, quelle qu’en soit l’origine.
Reste la question de la confidentialité. Avant d’adopter un assistant, il est utile de vérifier où partent les extraits de code, s’ils servent à entraîner le modèle et sous quelle juridiction ils sont traités. Les offres professionnelles permettent généralement d’exclure vos données de l’entraînement, et certains modèles peuvent fonctionner en local, sans quitter votre infrastructure. Les secrets, mots de passe et clés d’accès ne doivent jamais figurer dans le code partagé, et un projet qui manipule des données de santé ou des données personnelles sensibles mérite des règles écrites, connues de toute l’équipe, sur ce qui peut ou non être soumis à un assistant.
Faire développer avec l’IA à Tours, sans perdre la maîtrise
Chez ACKWA, à Saint-Avertin près de Tours, nous utilisons l’IA comme un outil de productivité, jamais comme un architecte. Chaque ligne livrée à un client est relue, testée et documentée par un développeur qui en répond, qu’il s’agisse d’un site WordPress, d’une application Symfony ou d’un module Odoo sur mesure. C’est ce qui permet de garder des applications maintenables et migrables, et de vous expliquer à tout moment ce que fait votre logiciel.
Pour un nouveau projet, découvrez notre approche du développement sur mesure et de la maintenance de vos applications. Si vos équipes utilisent déjà des assistants de code, nos formations et notre accompagnement aident à en encadrer l’usage, et notre article sur le module Odoo sur mesure montre comment nous concevons des développements durables. Pour en parler, contactez-nous.
Crédits photos : Yan Krukau via Pexels, mwitt1337 via Pixabay et Albert Stoynov via Unsplash.