Construire votre outil interne avec l'IA, oui, mais pas n'importe comment.

Vous avez raison de construire votre outil interne vous-même

Un outil que vous construisez vous-même, c'est d'abord un besoin que personne d'autre n'a pris au sérieux. Le tableur critique, la macro qui pilote la facturation, l'abonnement pris avec la carte du service : derrière chaque bricolage, il y a un problème réel que le système officiel n'a pas résolu. Vous n'êtes pas en faute : vous êtes le signal que le système officiel a manqué.

Construire soi-même en décrivant ce qu'on veut à une IA, ce que les développeurs appellent le vibe coding, est devenu une option sérieuse. Et le coût a changé de nature. Ce qui demandait un prestataire, un devis et 3 mois se fait en quelques sessions, pour le prix d'un abonnement. Des étudiants outillés par l'IA livrent en quelques semaines une première version de ce qu'un prestataire facturait 20 000 € il y a 3 ans. Refuser cet outil au nom de la prudence, c'est laisser le problème en place.

Ce qui a beaucoup moins baissé, c'est le prix des erreurs de conception : les repérer et décider quoi en faire demande toujours un regard humain, et elles arrivent plus vite, parce que vous construisez plus vite. Les 3 erreurs qui reviennent sont toujours les mêmes.

Les 3 risques d'un outil interne construit avec l'IA

Voici les 3, dans l'ordre où ils apparaissent, avec le signe qui les annonce, la cause, et ce qu'ils coûtent.

Risque 1 : l'outil à votre image, que vos utilisateurs n'adoptent pas

C'est le premier, et celui que personne n'attend, parce qu'il n'a rien de technique. Vous connaissez le métier mieux que quiconque, donc vous construisez l'outil qui vous manque. Chaque session ajoute une fonction dont vous avez besoin. Au bout de 2 mois, l'outil fait tout, et vos collaborateurs continuent d'utiliser le fichier d'avant.

L'outil d'estimation de loyers était complet, et il était aussi beaucoup trop compliqué pour quelqu'un qui n'avait pas le contexte du dirigeant, et personne n'avait regardé l'écran avec les yeux de l'utilisateur. Le résultat s'appelle une dette fonctionnelle : des fonctions, des règles et des écrans que personne n'ose retirer, et que personne ne sait plus justifier.

Repérez la dérive à 2 signes. Vous n'arrivez plus à expliquer l'outil en 2 minutes à un nouveau venu. Et vos collaborateurs ont développé un contournement, souvent un tableur, pour ne pas avoir à ouvrir votre outil.

La parade tient en une décision prise avant la première session : nommer 1 utilisateur qui n'est pas vous, et construire pour lui. Il teste chaque version. S'il hésite devant un écran, l'écran est à refaire. Et tenez la liste de ce que l'outil ne fera pas, sur une page : c'est cette page qui protège l'outil de vos propres ajouts.

Risque 2 : les décisions techniques que vous prenez sans le savoir

À chaque session, l'assistant prend des choix, ou vous les propose : où stocker les données, comment les utilisateurs se connectent, comment l'outil parle à votre messagerie ou à votre agenda. Vous dites oui, ou vous ne voyez même pas qu'il y avait une décision, parce que ce n'est pas votre métier. Vous prenez des décisions techniques que vous ne comprenez pas, et l'outil marche, donc rien ne vous alerte.

Le premier endroit où ça se voit, ce sont les cas limites. Un outil construit par quelqu'un qui n'a pas la vision technique gère le scénario optimiste, celui où tout se passe comme prévu, ce que les développeurs appellent le happy path. Prenez un outil qui se connecte à votre compte Google. Vous cliquez, Google vous demande des autorisations, vous refusez l'une d'elles par réflexe. Sur un outil relu, un écran vous propose de recommencer. Sur un outil construit sur le seul scénario optimiste, rien : vous êtes coincé, sans message, et sans raison de revenir.

Le deuxième endroit, c'est la sécurité, et là les conséquences changent d'échelle. Les applications construites sans relecture laissent des accès ouverts, des clés en clair, des données consultables par n'importe qui sachant où chercher. Ce n'est pas un jugement sur vous. L'accès mal verrouillé est le défaut classé numéro 1 par le référentiel des spécialistes de la sécurité des applications, en 2021 comme en 2025. Des équipes de développeurs professionnels le commettent aussi.

Et les attaques se multiplient. Il n'existe pas de chiffre propre pour le mesurer, mais le mécanisme est visible. Des modèles ouverts, que n'importe qui peut télécharger, mettent l'outillage d'une attaque à portée de main. Des gens qui n'en avaient pas les moyens il y a 2 ans l'ont aujourd'hui. Même l'administration fiscale française, censée figurer parmi les mieux protégées, a confirmé en août 2026 une intrusion et la fuite de plusieurs centaines de milliers de lignes de données. Un outil construit sans personne pour relire les choix part avec un handicap.

Et le risque ne s'arrête pas à vous. Il s'étend à tous ceux qui mettent leurs données dans votre outil : vos clients, vos collaborateurs, vos partenaires. Si un outil d'estimation fuit, ce sont les adresses et les loyers des propriétaires qui sortent. Si un outil de suivi commercial fuit, ce sont vos clients. Vous portez ce risque à partir du premier enregistrement réel.

Risque 3 : la dette technique qui ne se voit pas à l'écran

Quand vous construisez avec l'IA, vous jugez le résultat à l'écran. Est-ce que c'est joli, est-ce que c'est utilisable, est-ce que ça marche. Si la réponse est oui, vous passez à la suite sans regarder plus loin. Vous ne regardez presque jamais ce que l'outil fait à l'intérieur, ni comment il le fait. C'est normal, et c'est là que la dette s'installe.

Un exemple vu de près. Un outil qui traitait des données par lots faisait ses appels un par un : pour 100 lignes, 100 aller-retours vers le serveur. Avec 5 utilisateurs et quelques centaines de lignes, personne ne s'en aperçoit. Avec 100 fois plus de données, l'outil devient trop lourd et les traitements traînent. La correction n'est pas un réglage : il faut repasser sur chaque endroit construit de cette façon, et il y en a partout, alors qu'une autre façon de faire existait dès le départ, pour le même effort.

La dette non voulue a une particularité : vous ne l'avez pas choisie. Un développeur qui prend un raccourci sait qu'il le prend, et note qu'il faudra y revenir. Vous, vous avez hérité d'une direction de départ sans savoir qu'il y en avait une. Le produit peut être très propre en apparence, bien rangé, agréable à utiliser, et partir dans une direction qui oblige à jeter une grosse partie du travail le jour où il grandit.

Le signe qui ne trompe pas : vous demandez une petite modification, et l'IA touche à 10 endroits. Ou l'outil ralentit à mesure que les utilisateurs arrivent. Dans les 2 cas, ne le faites pas grossir avant d'avoir fait valider l'architecture technique.

Pourquoi l'IA ne vous protège pas de ces 3 risques

Un modèle plus récent ne réglera pas la question. Les 4 raisons tiennent à la façon dont vous travaillez avec lui, pas à son intelligence.

Elle fait ce qu'on lui demande, le reste une fois sur deux

Si vous ne demandez pas que les traitements soient regroupés, que les erreurs soient gérées ou que les accès soient vérifiés, elle le fera parfois, et parfois non, sans vous dire dans quel cas vous êtes. Même le modèle le plus intelligent du moment.

Elle travaille dans le périmètre de la session

Elle se concentre sur ce que vous lui demandez. Ce qui a été construit la semaine dernière, dans une autre session, elle ne le remet pas en question si personne ne le lui demande, même si c'est là que le problème se trouve.

Elle n'a pas de constance d'une session à l'autre, sauf celle que vous lui écrivez

Vous travaillez rarement en continu sur un projet : vous enchaînez des sessions, avec un cadrage différent à chaque fois. Le résultat change avec le cadrage, et l'ensemble finit par ne plus suivre une seule direction. Tous ces outils acceptent un fichier de consignes permanent : écrivez-y vos règles, et relisez-le à chaque session.

Elle produit du code qui a des failles, à un rythme connu

Un éditeur d'outils de sécurité a testé plus de 100 modèles sur 80 tâches de programmation où un choix de sécurité se posait, en 2025 : dans 45 % des cas, le code produit contenait une faille connue. Les modèles plus récents ne faisaient pas mieux sur ce point.

Les 2 raisons qui surprennent le plus sont le périmètre de la session et l'absence de constance d'une session à l'autre, parce qu'elles tiennent à votre façon de travailler. Vous travaillez par sessions, rarement en continu. À chaque session, vous décrivez ce que vous voulez, avec plus ou moins de précision, et l'IA construit dans ce cadre. Elle ne remet pas en cause ce qui a été fait avant, parce qu'on ne le lui a pas demandé. Session après session, l'outil se construit par couches, chacune cohérente avec sa demande du jour, et l'ensemble ne suit plus une seule direction. Aucun modèle ne corrige ça à votre place : c'est vous qui tenez la direction, ou personne.

L'IA vous dit aussi rarement non, quelle que soit la demande. Demandez une onzième fonction, elle l'ajoute ; demandez un traitement ligne par ligne, elle le fait aussi. Décider ce qu'il ne faut pas construire reste votre travail : l'IA ne le fera pas à votre place.

Les 6 règles à poser avant la première session de construction

Rien de ce qui suit ne demande de savoir coder. Tout se décide avant d'ouvrir l'assistant, sur une page. Les 6 règles :

1. 1

   Nommer 1 utilisateur qui n'est pas vous, et construire pour lui. S'il ne comprend pas un écran sans explication, l'écran est à refaire, pas l'utilisateur.

2. 2

   Tenir le périmètre de la première version sur une page : ce que l'outil fait, et la liste de ce qu'il ne fera pas. Une fonction qui n'est pas sur la page attend la version suivante.

3. 3

   Écrire les cas limites avant de demander à l'IA de coder : que se passe-t-il si l'utilisateur refuse une autorisation, ferme la fenêtre, saisit n'importe quoi, ou revient 6 mois plus tard ?

4. 4

   Aucune donnée réelle dans l'outil tant qu'il n'a pas été relu : pas de fichier clients, pas de données du personnel, pas de contrats. Des données fictives font très bien l'affaire pour construire.

5. 5

   Faire valider l'architecture technique par quelqu'un qui sait la lire, une fois, au départ : comment les données sont stockées, comment on se connecte, comment les traitements s'enchaînent. Une heure avec quelqu'un dont c'est le métier, avant la deuxième session.

6. 6

   Écrire vos règles dans le fichier de consignes permanent de l'outil, et demander à l'IA, à chaque session, de relire ce qu'elle a fait avant de construire la suite. Ce n'est pas une garantie, c'est un filet.

La cinquième règle est celle qui rapporte le plus pour ce qu'elle coûte. Une heure de validation de l'architecture technique, au départ, évite la plupart des réécritures de dette non voulue. Vous n'avez pas besoin d'un prestataire pour construire : vous avez besoin de quelqu'un qui regarde l'intérieur une fois, au bon moment, et qui vous dit dans quelle direction vous partez.

Quand faire relire votre outil interne, et quoi

Vous n'avez pas besoin d'une relecture permanente. Vous avez besoin d'une relecture à 4 moments, parce que ce sont ceux où le coût d'une erreur change d'échelle. Et si votre outil tourne déjà avec des données réelles, les 4 angles morts du dirigeant qui automatise seul sont détaillés dans un autre décryptage. Les 4 moments :

Avant d'y mettre des données réelles

Le jour où des données clients, des salaires ou des contrats entrent dans l'outil, votre problème de bricolage devient un problème de responsabilité. Faites vérifier où ça part, qui y accède, et comment on efface.

Avant le dixième utilisateur

À 1 utilisateur, vous pardonnez tout. À 10, un écran bloqué est un ticket. C'est le bon moment pour faire relire les cas limites et la gestion des erreurs, tant que la correction reste petite.

Avant de brancher l'outil sur autre chose

Une connexion à votre messagerie, à votre facturation ou à votre agenda multiplie les autorisations et les points de panne. Mieux vaut une relecture d'une heure avant qu'une coupure de service après.

Quand l'outil ralentit

Un outil qui ralentit avec le nombre d'utilisateurs dit quelque chose de sa conception. Ne le faites pas grossir avant d'avoir compris pourquoi.

Ce que la relecture regarde, dans l'ordre : où sont les données et qui y accède, comment les erreurs sont gérées, et dans quelle direction l'outil est construit. Elle se termine par une décision écrite : continuer tel quel, durcir ce qui existe, ou refaire une partie avant d'aller plus loin. Refaire tôt coûte quelques jours, refaire tard peut coûter l'outil.

Et si la relecture arrive après coup, sur un outil qui a déjà grandi et dont quelqu'un d'autre dépend, vous êtes dans un autre sujet. C'est la reprise d'un projet informatique, avec sa grille pour décider entre recadrer, reprendre ou repartir.

Comment décider : la séquence, dans l'ordre

Les 7 étapes, dans cet ordre :

1. 1

   Écrire le problème en une phrase, et le nom de la personne qui l'a. Si c'est vous seul, l'outil est un outil personnel, et tout le reste devient facultatif.

2. 2

   Écrire le périmètre de la première version sur une page, et la liste de ce qui attend.

3. 3

   Lister les cas limites, au moins les 5 évidents, et les donner à l'IA avec la demande.

4. 4

   Faire valider l'architecture technique par quelqu'un qui sait la lire, une fois, au départ, avant la deuxième session.

5. 5

   Tester, beaucoup, et sur des données fictives : les branchements avec vos autres outils, les cas limites, la sécurité, les comportements à risque, et l'expérience de l'utilisateur nommé à l'étape 1.

6. 6

   Faire auditer le projet par quelqu'un dont c'est le métier dès que d'autres personnes que vous l'utilisent : la sécurité, l'architecture, les cas limites. Plus l'outil a vocation à durer, moins cette étape est facultative.

7. 7

   Assumer les décisions que l'audit impose : refondre une partie, réécrire, changer le produit. Vous savez maintenant ce qui ne va pas, et attendre ne le rendra pas moins cher.

Avec cette séquence, vous gardez la vitesse, qui est la raison de faire. Vous perdez seulement la partie de l'outil qui n'aurait pas survécu de toute façon, et vous la perdez au moment où ça coûte le moins.

Questions fréquentes

Sources

Références consultées pour cette version du 21 août 2026. Les cas cités sont réels et anonymisés.

• Veracode, « 2025 GenAI Code Security Report », test de plus de 100 modèles sur 80 tâches ↗
• OWASP Top 10:2025, les 10 risques les plus fréquents des applications web ↗