Il y a quelques années, fabriquer un petit outil interne demandait souvent de trouver quelqu’un qui savait coder.
Puis le no-code a simplifié une partie du sujet.
Maintenant, on arrive à l’étape suivante : décrire ce qu’on veut en langage naturel et laisser l’IA construire une partie de l’application.
Le 25 septembre, Microsoft a présenté une nouvelle version de Copilot avec notamment Code, une capacité destinée à permettre à davantage de personnes de créer des solutions et des automatisations sans être développeur.
C’est une très bonne nouvelle.
Et ça va probablement fabriquer un nouveau bazar si on ne garde pas une trace de ce qui est créé.
Le logiciel maison va devenir beaucoup plus facile à fabriquer
Dans une petite entreprise, les outils internes apparaissent toujours de la même façon.
Quelqu’un en a marre d’une tâche. Il construit un fichier. Puis une macro. Puis un formulaire. Puis « juste un petit truc pour gagner du temps ».
Six mois après, le petit truc est utilisé tous les jours.
Avec l’IA, cette trajectoire peut aller beaucoup plus vite.
Une personne qui connaît parfaitement son métier peut fabriquer elle-même une interface, un suivi ou une automatisation sans attendre un projet informatique.
C’est excellent pour tester.
Mais le jour où trois collègues utilisent l’outil, ce n’est plus seulement une expérimentation personnelle.
Il faut savoir qu’il existe.
Je créerais un inventaire avant de créer une DSI
Pas besoin d’une architecture compliquée.
Un simple tableau peut suffire.
Nom de l’outil. À quoi il sert. Qui l’a créé. Où il vit. Quelles données il utilise. Qui sait le réparer. Que fait-on s’il ne fonctionne plus.
Ça paraît presque trop simple.
Pourtant, c’est exactement ce qui manque quand l’auteur du petit outil part en congé et que tout le monde découvre que le planning du service dépend d’une application dont personne ne connaît le fonctionnement.
À La Flèche comme ailleurs, une petite boîte n’a pas besoin de transformer chaque prototype en projet informatique.
Elle a besoin de savoir lesquels sont devenus importants.
Le risque n’est pas que les salariés construisent
Je ne voudrais surtout pas que la conclusion soit : « il faut empêcher les gens de créer des outils ».
Ce serait dommage.
Les meilleurs prototypes viennent souvent de la personne qui subit le problème tous les jours.
Elle connaît les exceptions. Elle sait ce qui est pénible. Elle voit immédiatement si l’outil aide vraiment.
Le bon cadre doit donc permettre d’essayer facilement.
Puis déclencher une deuxième étape lorsque l’usage grandit.
À partir de quand faut-il sauvegarder autrement ? Documenter ? Ajouter des droits ? Tester les erreurs ? Prévoir une personne de secours ?
Ce passage du prototype à l’outil collectif doit devenir visible.
Le langage naturel ne supprime pas le cycle de vie
Créer devient moins cher.
Maintenir ne devient pas gratuit.
Une règle métier change. Un connecteur disparaît. Une source de données bouge. Un champ est renommé. Une personne n’a plus le droit d’accéder à certaines informations.
L’application doit suivre.
Et si elle traite des données personnelles, le fait qu’elle ait été créée en langage naturel plutôt qu’en code ne change rien aux obligations qui entourent ces données.
Même chose pour les données sensibles. Santé, opinions politiques, convictions religieuses, appartenance syndicale, données biométriques ou orientation sexuelle font partie des catégories particulièrement protégées par le RGPD. La CNIL rappelle que ces traitements demandent une vigilance renforcée et ne deviennent pas plus simples parce que l’application a été créée en quelques prompts.
Le vrai sujet n’est donc pas de savoir si quelqu’un « a le droit de coder ».
C’est de savoir quand son petit outil est devenu assez utile pour mériter une place dans le fonctionnement de l’entreprise.
Avec l’IA, on va probablement créer beaucoup plus de logiciels maison.
Autant commencer à savoir où ils sont.
Sources
- Microsoft, 25 septembre 2026.
Vous avez un sujet concret à regarder dans votre entreprise ? Parlons-en.