Un formulaire de devis, un portail client, un outil de planning : avec les outils de code IA, c’est debout en quelques jours au lieu de plusieurs mois. C’est un vrai progrès et nous ne conseillons à personne de revenir en arrière. Mais nous regardons sous le capot de ces applications par métier et le même tableau ressort à chaque fois. Le logiciel fait ce que la démo promet. Les problèmes se trouvent dans tout ce que la démo ne montre pas.
Quels sont les risques d’un logiciel construit avec l’IA ?
Un logiciel construit avec l’IA tourne le plus souvent sans accroc en démo et échoue sur ce qu’on ne voit pas : validation des saisies absente, API ouvertes à qui connaît l’adresse, données personnelles qui fuient, obligations RGPD couvertes nulle part et logique métier qui tourne dans le navigateur au lieu du serveur. Des chercheurs de NYU ont constaté dès 2021 qu’environ quarante pour cent du code généré par IA contenait des vulnérabilités. Chacune de ces failles peut être établie et corrigée, de préférence avant la mise en ligne.
Tout le monde construit soi-même et ce n’est pas un mal
La barrière pour créer un logiciel s’est effondrée en deux ans. Ce qui demandait une équipe de développement et six mois, un collaborateur habile le fait maintenant en quelques semaines. Pour une PME, c’est une chance : vous connaissez votre fonctionnement mieux que n’importe quel prestataire et vous pouvez enfin créer des outils qui collent exactement à votre processus.
Le problème n’est pas la construction. Le problème est que les outils optimisent pour du code qui fonctionne et pas pour du code sûr, et que le constructeur n’a le plus souvent pas le bagage pour voir la différence. L’application tourne, tout le monde est content et personne ne pose la question qu’un développeur professionnel pose en premier : que se passe-t-il quand quelqu’un l’utilise mal ?
Les cinq failles qui reviennent toujours
Voici les cinq schémas que nous rencontrons le plus dans les revues d’applications auto-construites. Chacun est invisible en démo et chacun fait mal après la mise en ligne.
1. Les saisies ne sont pas contrôlées
Un formulaire attend un nom et une adresse e-mail. Que se passe-t-il si quelqu’un y colle un bout de code, un fichier de 2 gigaoctets ou un texte de dix mille caractères ? Sans validation, tout cela atterrit sans filtre dans votre base de données ou dans les mails vers votre équipe. Cela commence par du bruit dans vos données et finit par un attaquant qui lit votre base via un champ de saisie.
2. L’API est ouverte à qui connaît l’adresse
Derrière chaque application se trouve une couche qui lit et écrit les données. Les outils IA montent souvent cette couche sans contrôler qui frappe à la porte. Qui connaît l’adresse ou la devine peut alors consulter directement commandes, données clients ou prix sans jamais se connecter. Et l’adresse figure en clair dans le code que chaque navigateur reçoit.
3. Les données personnelles fuient par la porte de côté
Des messages d’erreur qui montrent la fiche client complète, des boutons d’export sans contrôle des droits, des fichiers de logs pleins d’adresses e-mail : les applications auto-construites fuient rarement par la porte d’entrée et presque toujours par une porte de côté oubliée. Une fuite suffit pour une notification à l’autorité de protection des données et une conversation pénible avec chaque client concerné.
4. Le RGPD n’est couvert nulle part
Qui traite les données, où sont-elles stockées, combien de temps et sur quelle base ? Un outil IA ne pose pas ces questions et le constructeur le plus souvent non plus. Et voilà une application qui envoie des données clients vers un service américain sans contrat de sous-traitance, sans mention dans la déclaration de confidentialité et sans que personne ne s’en rende compte.
5. La logique métier tourne dans le navigateur
Le classique des configurateurs et outils de devis : le calcul de prix se trouve dans le code envoyé au visiteur. Quiconque a un navigateur peut lire et modifier ce code. Au mieux, un concurrent lit votre structure de remises. Au pire, quelqu’un commande à un prix qu’il a saisi lui-même et vous avez un problème juridique, car la commande est confirmée.
Pourquoi la démo ne vous dit rien
Une démo montre le chemin attendu : des saisies correctes, un utilisateur bienveillant et aucun attaquant. Précisément les trois hypothèses qui tombent après la mise en ligne. Les vrais utilisateurs font l’inattendu, les bots scannent chaque URL publique en quelques jours et les formulaires reçoivent leur premier spam automatisé dans la semaine. La question n’est pas si cela tourne mal mais si quelqu’un le remarque quand cela tourne mal, et c’est rarement prévu dans les applications auto-construites : journalisation et alertes manquent presque toujours.
Ce que vous pouvez vérifier vous-même aujourd’hui
Quatre contrôles sans bagage technique. Échouez à un seul et vous savez qu’il y a plus.
Un : saisissez quelque chose de faux dans chaque champ. Du texte où un chiffre est attendu, un champ obligatoire vide, un nom absurdement long. Recevez-vous des messages d’erreur propres ou l’application se comporte-t-elle bizarrement ? Deux : ouvrez l’application en navigation privée et collez l’adresse d’une page qui devrait être derrière la connexion. Si vous voyez quand même des données, la porte est ouverte. Trois : demandez qui détient les contrats de sous-traitance avec chaque service externe utilisé. Le silence est une réponse. Quatre : demandez au constructeur où tourne le calcul de prix. Si la réponse est « dans l’application », demandez si c’est le serveur ou le navigateur.
Faites-le tester avant la mise en ligne
Construire soi-même et faire tester professionnellement ne s’excluent pas ; ils vont ensemble. Nous menons des audits logiciels sur exactement ce type d’applications : six domaines de contrôle, de la sécurité et du RGPD aux scénarios de test fonctionnels et à la continuité, avec un rapport qui marque par constat ce qui est critique et ce qui peut attendre. Votre équipe continue ensuite à construire, mais avec les failles refermées.
Construit vous-même et presque prêt pour la mise en ligne ?
L’audit logiciel SEMANU examine votre application sur les six domaines de cet article et livre une liste de priorités plus une session de travail avec votre équipe. Approche fixe, à partir de 1 850 euros.
Questions fréquentes
Un logiciel construit avec l’IA est-il dangereux ?
Pas par définition, mais la probabilité de failles est plus élevée. Des chercheurs de NYU ont constaté dès 2021 qu’environ quarante pour cent du code généré par IA contenait des vulnérabilités. Les outils optimisent pour du code qui fonctionne et pas pour du code sûr.
Dois-je alors arrêter de construire avec l’IA ?
Non, et pour beaucoup d’outils internes c’est la voie la plus rapide. Le point est qu’une application qui touche des clients, de l’argent ou des données personnelles soit testée avant la mise en ligne, exactement comme on fait inspecter une cuisine rénovée soi-même avant de raccorder le gaz.
Que contrôle exactement un audit logiciel ?
Six domaines : sécurité, données personnelles et RGPD, comportement fonctionnel avec scénarios de test, architecture et logique, performances et usage mobile, et continuité. Le résultat est un rapport avec une liste de priorités à trois niveaux et une session de travail avec votre équipe.
Combien coûte un tel audit et combien de temps dure-t-il ?
À partir de 1 850 euros hors TVA, avec un délai d’environ une semaine. Pour la pleine profondeur, nous demandons un accès en lecture au code sous accord de confidentialité mutuel ; sans accès au code, une variante boîte noire existe.