Les outils internes se multiplient avec l'IA, mais personne ne prévoit leur maintenance. Questions à poser avant de laisser un employé construire seul un outil dont dépend l'entreprise.
C'est une scène devenue banale : un salarié curieux, un peu bricoleur, branche un assistant IA sur les données de son service, construit un tableau de bord et un script d'automatisation. Six mois plus tard, l'outil est indispensable. Et son auteur vient d'annoncer son départ.
La question n'est pas de savoir s'il faut empêcher ce genre d'initiative — c'est souvent là que naissent les gains de productivité les plus réels. La question est de savoir ce qui reste quand la personne s'en va. Voici les points à vérifier avant que la situation ne devienne un problème.
Le vrai coût d'un outil invisible
Un outil construit en solo fonctionne rarement comme une application classique. Il repose sur un enchaînement de dépendances fragiles : un fichier partagé, une clé API stockée dans une variable d'environnement, un script déclenché manuellement, une formule dans un tableur. Tant que l'auteur est là, tout tient. Son absence révèle la dette.
Le risque n'est pas seulement technique. C'est un risque de continuité : un rapport automatisé qui alimente une décision commerciale, un formulaire qui collecte des demandes clients, un tableau de bord dont dépend une équipe. Le jour où le script tombe, personne ne sait à qui appartient le problème.
On parle souvent de « shadow IT » pour désigner ces outils. Le terme est un peu moralisateur. Il vaudrait mieux parler d'outils non répertoriés : ils existent, ils servent, ils ne sont simplement inscrits nulle part.
Quatre questions à poser avant de laisser quelqu'un construire seul
Ces questions ne visent pas à décourager l'initiative, mais à rendre explicite ce qui est implicite.
- Qui d'autre sait faire tourner l'outil ? Si la réponse est « personne », il faut agir maintenant, pas au moment du départ.
- Quelles données l'outil manipule-t-il, et où sont-elles ? Un outil qui copie des données clients dans un fichier local est un problème de conformité autant que de maintenance.
- Que se passe-t-il si une dépendance externe change ? Une API modifiée, un modèle IA déprécié, un fournisseur qui change ses tarifs : l'outil survivra-t-il ?
- Qui décide de l'arrêter ? Un outil dont plus personne ne mesure l'usage réel devient un coût caché.
Une bonne pratique simple : tenir un registre des outils internes, avec pour chacun un propriétaire nommé, une description en deux lignes, les données utilisées et la date du dernier contrôle. Un tableur suffit pour commencer.
Low-code ou code sur mesure : ce n'est pas la question principale
On oppose souvent les plateformes low-code au développement sur mesure. Le débat est utile, mais il passe à côté de l'essentiel : la maintenance. Une application low-code peut être très difficile à reprendre si elle a été construite sans documentation et sans conventions. À l'inverse, un petit projet en code sur mesure, bien structuré et versionné, se reprend en quelques heures.
Ce qui compte, c'est la reprise possible :
- Le code et les configurations sont-ils dans un dépôt accessible à l'entreprise, pas seulement sur le poste de l'auteur ?
- Existe-t-il un fichier de documentation minimal : à quoi sert l'outil, comment le lancer, quelles variables configurer, qui contacter ?
- Les secrets et les clés sont-ils stockés dans un gestionnaire partagé, jamais dans le code ni dans un message ?
- Y a-t-il au moins une personne capable de faire une modification simple sans l'auteur ?
Si la réponse est non à l'une de ces questions, l'outil est en réalité une dépendance à une personne.
Ce que la gouvernance « citizen developer » doit réellement couvrir
Laisser les équipes métier construire leurs outils est une bonne idée, à condition d'encadrer trois choses, sans bureaucratie excessive.
Un seuil de passage en revue. En dessous d'un certain niveau d'usage ou de criticité, l'outil reste local. Au-dessus — s'il touche des données clients, alimente une décision récurrente ou est utilisé par plusieurs équipes — il passe par un point de contrôle technique léger : revue du stockage des secrets, de la documentation, de la propriété du dépôt.
Un principe de double compétence. Pour tout outil critique, une seconde personne doit savoir le relancer. Cela peut se faire en une heure d'accompagnement, pas en une formation longue.
Un rituel de transmission. Quand quelqu'un quitte son poste, la liste des outils qu'il a construits fait partie de la passation, au même titre que ses dossiers en cours. C'est une case à ajouter dans le processus de départ, pas un projet.
Le cas particulier des outils IA
Les outils internes qui s'appuient sur des modèles IA ajoutent une couche de fragilité : les modèles évoluent, les API changent de version, les coûts varient avec l'usage. Un assistant qui fonctionne aujourd'hui peut se dégrader sans qu'une ligne de code ait bougé.
Prévoyez donc, pour ces outils, un mécanisme de détection : un test simple qui vérifie que la chaîne répond, un suivi du coût mensuel, une alerte si le volume d'appels s'effondre ou explose. Et documentez le choix du fournisseur : pourquoi ce modèle, quelles alternatives, comment basculer. C'est ce qui distingue un prototype d'un outil dont l'entreprise peut dépendre.
La bonne question à se poser aujourd'hui
Parcourez la liste des outils qui font tourner votre organisation. Pour chacun, demandez-vous : si la personne qui l'a construit part demain, que se passe-t-il lundi matin ? Si la réponse vous met mal à l'aise, il n'est pas trop tard — mais il est plus simple de régler cela maintenant que dans l'urgence.
Parlons de votre situation
Si vous avez des outils internes construits par des équipes métier et que vous voulez savoir lesquels méritent d'être consolidés, documentés ou simplement arrêtés, c'est un bon point de départ pour une conversation. Décrivez-moi ce qui existe aujourd'hui et ce qui vous inquiète : contact@hamzabelgacem.com.