Les employés créent désormais leurs propres outils avec le no-code et l'IA. Sans propriétaire, documentation ni reprise prévue, ces outils deviennent une dette invisible dès que leur créateur part. Voici les questions à poser avant d'autoriser ce mouvement.
Le scénario est devenu banal. Un responsable commercial construit lui-même, en quelques après-midis, un tableau de bord qui agrège ses ventes, ses relances et un assistant IA qui résume ses comptes rendus de rendez-vous. L'outil fonctionne, l'équipe l'adopte, tout le monde gagne du temps. Puis la personne change de poste, part chez un concurrent ou prend un congé long. Et là, personne ne sait comment l'outil est branché, d'où viennent les données, ni pourquoi une automatisation précise échoue un mardi sur deux.
Ce n'est pas un cas isolé. C'est le revers prévisible d'une tendance saine : les métiers les plus proches du terrain construisent désormais leurs propres outils avec le no-code et l'IA générative. Le problème n'est pas que les employés créent des outils. Le problème est qu'on les laisse faire sans se poser la question de la reprise.
Pourquoi ces outils deviennent invisibles
Un outil construit par un employé pour son usage quotidien naît souvent en dehors de tout inventaire. Il n'est pas dans le SI officiel, il n'a pas de ticket, pas de budget, pas de propriétaire désigné. Il vit dans un compte personnel, branché sur une feuille de calcul partagée et une clé API oubliée quelque part.
Tant que son créateur est là, cet outil paraît gratuit. Dès qu'il s'en va, le coût apparaît d'un coup : il faut comprendre la logique, retrouver les accès, vérifier ce qui tourne encore, décider quoi garder. C'est la définition d'une dette technique invisible : elle ne se voit pas tant que personne ne touche au système.
Le no-code amplifie le phénomène parce qu'il rend la construction accessible à des personnes qui ne documentent pas naturellement leur travail. Ce n'est pas un défaut de compétence, c'est une question de rôle : un développeur sait qu'un outil devra être repris un jour, un opérationnel qui gagne deux heures par jour pense d'abord à son propre confort.
Les questions à poser avant d'autoriser
Plutôt que d'interdire, ce qui pousserait simplement ces outils dans l'ombre, posez quelques questions simples dès qu'un employé veut automatiser quelque chose d'un peu structurant.
- Qui est propriétaire de l'outil ? La réponse doit être un rôle, pas seulement une personne. Si le propriétaire est aussi le seul utilisateur et le seul mainteneur, le risque est maximal.
- D'où viennent les données et où vont-elles ? Un outil qui envoie des données clients à un service externe sans que personne ne le sache pose un problème de conformité, pas seulement de maintenance.
- Que se passe-t-il si l'auteur s'absente deux semaines ? Si la réponse est « on ne sait pas », l'outil n'est pas prêt à être utilisé en production.
- Qui peut le modifier ? Un outil que personne d'autre ne sait éditer est un point de fragilité, même s'il fonctionne parfaitement aujourd'hui.
- Que se passe-t-il quand une API change ou qu'un modèle IA est mis à jour ? Les intégrations cassent, les modèles évoluent. Sans surveillance, la panne sera découverte par un utilisateur mécontent, pas par un mainteneur.
Ces questions ne demandent pas de créer une bureaucratie. Elles tiennent sur une demi-page et se posent en dix minutes.
Ce qui rend une reprise possible
La reprise d'un outil no-code ou IA au départ de son créateur repose sur trois éléments concrets, et aucun ne demande de compétences de développeur.
La documentation minimale. Une page qui décrit à quoi sert l'outil, quelles données il utilise, quels services il appelle, où se trouvent les accès et quelles sont les limites connues. Une page suffit. L'absence de documentation est presque toujours ce qui transforme un outil utile en boîte noire.
La propriété partagée. Au moins deux personnes doivent avoir accès à l'outil, savoir le modifier et comprendre son fonctionnement. C'est la meilleure assurance contre le départ brutal.
Un inventaire léger. Une liste de tous les outils construits en interne, avec leur propriétaire, leur statut et leur criticité. Cette liste n'a pas besoin d'être exhaustive pour être utile : elle sert surtout à savoir ce qui existe et ce qui compte.
Le rôle de la gouvernance
La gouvernance du no-code en entreprise n'a pas pour but de ralentir. Elle a pour but de rendre le mouvement durable. Un citizen developer qui sait qu'il devra documenter son outil et désigner un second utilisateur construira différemment, avec un peu plus de soin et beaucoup moins de risque.
Le bon équilibre ressemble souvent à ceci : liberté totale pour les prototypes et les usages personnels, cadre léger dès qu'un outil est partagé par plusieurs personnes ou manipule des données sensibles, et revue formelle dès qu'il devient critique pour une équipe. Trois niveaux, pas un seul.
Pour la maintenance des outils internes qui intègrent de l'IA, ajoutez un point spécifique : les modèles et les API évoluent, les coûts varient, les prompts se périment. Un outil IA sans surveillance active se dégrade silencieusement, même quand son auteur est toujours là.
Ce qu'il faut retenir
Le départ d'un employé qui a construit ses propres outils n'est pas un accident. C'est un événement prévisible, au même titre qu'un changement de fournisseur ou une mise à jour de logiciel. La seule vraie question est de savoir si l'organisation l'a anticipé.
Autoriser les employés à construire avec le no-code et l'IA est une bonne décision. Le faire sans demander qui reprendra l'outil en cas d'absence, c'est accepter de créer une dette que personne ne verra avant qu'elle ne coûte cher.
Si vous vous reconnaissez dans ce scénario, ou si vous voulez poser un cadre simple avant que les outils ne se multiplient, parlons-en. Quelques échanges suffisent souvent à identifier les points de fragilité et à décider quoi documenter en priorité. Vous pouvez me joindre à contact@hamzabelgacem.com.