Outil créé avec l'IA en entreprise, les 7 risques à vérifier (2026)

Il y a quelques mois, vous ou quelqu'un de votre équipe avez construit un outil avec ChatGPT ou Claude. Un suivi des commandes, un planning, un petit CRM maison. Il marche, l'équipe l'utilise tous les jours, et vous n'avez pas eu à payer un logiciel qui ne collait pas à votre métier.

Pourtant, on peut se poser plusieurs questions. Que se passe-t-il si ça casse ? Où sont stockées les données de nos clients ? Et si la personne qui l'a construit s'en va ?

Voici les 7 risques à vérifier sur un outil créé avec l'IA, chacun avec un test simple à faire vous-même.

Pourquoi un outil créé avec l'IA devient-il risqué en entreprise ?

Un outil créé avec l'IA n'est pas risqué parce qu'il vient de l'IA. Il le devient quand il passe du statut d'essai à celui d'outil critique. Et cela sans les vérifications habituelles avant une mise en production (le moment où l'outil sert pour de vrai).

C'est presque toujours progressif. On commence par un tableau pour dépanner. Puis on ajoute une automatisation, un formulaire, un script écrit par ChatGPT. Six mois plus tard, toute la prise de commandes passe par là.

Les outils de création par IA (ChatGPT, Claude, Cursor, Lovable, Bolt) et le no-code (Airtable, Make, Zapier, Bubble) sont excellents pour aller vite. Ce qu'ils ne font pas tout seuls, c'est la sécurité et la maintenance dans la durée.

Le rapport 2026 de Veracode sur le code généré par l'IA l'illustre bien. Dans leurs tests, environ 44 % des tâches de code confiées à l'IA ont produit une faille de sécurité connue. Le code était pourtant presque toujours correct sur la forme. Il fonctionne, mais il n'est pas forcément sûr.

Quels sont les 7 risques à vérifier sur un outil créé avec l'IA ?

Les sept risques sont la dépendance à une personne, l'accès aux données, le RGPD, les sauvegardes, les pannes, les comptes dispersés et les évolutions bloquées. Chacun se vérifie en quelques minutes, sans compétence technique.

1. Une seule personne sait comment ça marche

C'est le risque le plus courant, et souvent le plus grave. L'outil a été construit par le dirigeant, un associé, un responsable des opérations ou un alternant, et tout est dans sa tête.

Si cette personne est absente ou quitte l'entreprise, plus personne ne sait corriger une erreur. Le cas de l'alternant est typique, l'outil devient indispensable et la connaissance part avec lui à la fin du contrat.

Le test. Demandez-vous qui peut corriger l'outil si son créateur est absent deux semaines. Si la réponse est « personne », c'est le premier risque à traiter.

2. Les données sont plus accessibles que vous ne le pensez

Un outil créé vite laisse souvent des portes ouvertes. Une base Airtable partagée à « toute personne disposant du lien ». Un Google Sheets public. Une page d'application accessible sans mot de passe. Une clé API (le code secret qui donne accès à un service payant ou à vos données) écrite en clair dans le code.

Rien de tout ça ne se voit à l'usage. L'outil fonctionne parfaitement, jusqu'au jour où quelqu'un tombe sur le lien.

Le test. Ouvrez le lien de votre outil dans une fenêtre de navigation privée, sans être connecté. Puis ouvrez les paramètres de partage de chaque fichier ou base, et regardez qui a accès.

3. Le RGPD n'a pas été pensé au départ

Dès que l'outil contient des noms, des téléphones ou des informations sur vos salariés, le RGPD s'applique. Et c'est votre entreprise qui en est responsable.

La CNIL demande de prendre des mesures techniques et organisationnelles adaptées pour protéger ces données. Son guide de la sécurité des données personnelles détaille les précautions de base (contrôle des accès, traçabilité, sauvegardes). Un outil bricolé en un week-end en coche rarement la moitié.

Le test. Listez tous les services par lesquels passent vos données (Airtable, Make, Google, l'hébergeur de l'application, l'API IA). Pour chacun, notez où les données sont hébergées. Un hébergement hors de l'Union européenne demande des garanties particulières.

4. Il n'y a pas de sauvegarde, ou personne ne l'a jamais testée

La CNIL recommande des sauvegardes fréquentes des données. Dans un outil fait maison, elles sont souvent absentes, ou bien elles existent mais personne n'a jamais essayé de les restaurer.

Le danger est réel avec l'IA. Une modification demandée à ChatGPT ou à Cursor peut réécrire un fichier entier. Une mauvaise manipulation dans une base peut effacer des centaines de lignes.

Le test. Posez la question simplement. Si toutes les données de l'outil disparaissaient ce soir, pourriez-vous retrouver celles d'hier ? Et combien de temps cela prendrait-il ?

5. Les pannes sont silencieuses

Une automatisation qui s'arrête ne prévient pas. Un mot de passe expiré, un quota atteint, une colonne renommée, et le scénario Make ou le script ne tourne plus.

Personne ne s'en rend compte avant qu'un client appelle pour une relance jamais reçue ou une commande jamais traitée. Les développeurs appellent ça la supervision (des alertes qui signalent qu'un traitement a échoué). Dans un outil maison, elle n'existe presque jamais.

Le test. Si votre automatisation principale s'était arrêtée hier soir, comment le sauriez-vous ? Si la réponse est « quand un client se plaindra », il manque une alerte.

6. Les coûts et les comptes sont dispersés

Un outil no-code ou créé avec l'IA repose souvent sur plusieurs abonnements (Airtable, Make, un hébergeur, une API IA). Les tarifs changent, les quotas se remplissent, et la facture monte sans qu'on l'ait décidé.

Il y a plus grave. Ces comptes sont parfois ouverts avec l'adresse email personnelle de la personne qui a créé l'outil. Si elle part, l'entreprise peut perdre l'accès à son propre outil.

Le test. Faites la liste de chaque service dont l'outil dépend. Pour chacun, notez à quelle adresse email le compte est ouvert et qui le paie. Tout compte qui n'est pas au nom de l'entreprise est à récupérer.

7. Plus personne n'ose y toucher

C'est le signe qu'un outil est arrivé au bout de sa construction « au fil de l'eau ». Chaque modification en casse une autre. Le fichier Excel a 40 onglets reliés par des formules que personne ne comprend. Le code généré par l'IA s'est empilé sans organisation.

Résultat, l'outil ne suit plus l'entreprise. On renonce aux évolutions, on ajoute des contournements à la main, et on ne peut pas le relier aux autres logiciels (comptabilité, facturation, logiciel métier).

Le test. Pensez à la dernière fois que vous avez voulu changer quelque chose. Combien de temps cela a-t-il pris, et est-ce que quelque chose d'autre a cassé au passage ?

Les 7 risques en un coup d'œil

Comment savoir si votre outil est devenu critique ?

Un outil est critique si son arrêt d'une journée bloque votre activité, ou s'il contient des données clients, salariés ou de facturation. Dans ce cas, les 7 risques méritent une vérification sérieuse.

Répondez par oui ou non à ces cinq questions.

• l'outil est utilisé tous les jours par plusieurs personnes ;
• il contient des données personnelles de clients ou de salariés ;
• il sert à facturer, à commander ou à planifier le travail des équipes ;
• une panne d'une journée coûterait des heures de travail ou des clients ;
• une seule personne sait vraiment comment il fonctionne.

Deux oui ou plus, votre outil est devenu critique. Il n'est pas pour autant en danger, mais il mérite le même soin qu'un logiciel acheté ou développé par un professionnel.

Réparer, reprendre ou reconstruire, que faire de votre outil ?

Le plus souvent, il n'est pas nécessaire de tout reconstruire. On garde ce qui fonctionne, on sécurise ce qui est exposé, et on ne reprend que les parties devenues impossibles à maintenir.

Votre outil a une vraie valeur. Il reflète votre façon de travailler, et votre équipe l'a testé au quotidien.

Si vous hésitez entre reprendre et reconstruire, notre guide complet du logiciel sur mesure pour les PME détaille les étapes d'un projet. Pour le budget, l'article sur le prix réel d'un logiciel sur mesure donne des fourchettes chiffrées.

Quand ce n'est pas la peine de s'inquiéter

Si votre outil n'a pas de données sensibles et qu'une panne d'une semaine ne changerait rien, laissez-le tranquille. Le faire auditer serait de l'argent mal dépensé.

C'est le cas d'un tableau de suivi personnel, d'un prototype monté pour tester une idée, ou d'un outil créé pour un événement ponctuel. Ce sont justement les usages où l'IA et le no-code sont imbattables.

Ne remplacez pas non plus un outil qui marche parce qu'il a été fait maison. Si les tests ne révèlent rien d'inquiétant, votre équipe a fait du bon travail. Refaites le point dès que l'outil prend plus de place.

Par où commencer ?

Commencez par un inventaire d'une heure, sans aide extérieure. Listez chaque outil fait maison, la personne qui l'a créé, les données qu'il contient et ce qui se passerait s'il s'arrêtait. Puis faites les 7 tests de cet article sur le plus critique.

Traitez d'abord ce qui est rapide et qui protège le plus.

• fermer les partages publics et les liens ouverts ;
• transférer les comptes au nom de l'entreprise ;
• mettre en place une sauvegarde, et tester une restauration ;
• ajouter une alerte sur l'automatisation la plus importante ;
• demander au créateur de l'outil d'écrire une page qui explique comment il fonctionne.

Si vous préférez un regard extérieur, c'est exactement ce que nous faisons avec l'audit d'un outil créé avec l'IA. En une journée, nous regardons ce qui est récupérable, à réparer ou à laisser tel quel. Vous repartez avec un plan priorisé.

Pour un suivi dans la durée, notre renfort technique à temps partiel vous accompagne un jour par semaine.