L'informatique de l'ombre, version 2026
Le no-code déplace la construction d'outils vers les métiers, ce qui est son intérêt principal : la personne qui connaît le besoin construit elle-même.
Le revers arrive plus tard. Des processus d'entreprise finissent par dépendre d'automatisations que le service informatique ne connaît pas, construites par une personne, branchées sur ses comptes, sans documentation.
Le jour où cette personne part ou change de poste, personne ne sait comment les commandes arrivaient dans le tableau de suivi.
Les quatre questions qui révèlent le risque
À poser sur chaque workflow existant. Elles prennent une minute et classent immédiatement.
Un processus d'entreprise en dépend-il ? Si oui, ce n'est plus un outil personnel.
Sur quels comptes est-il branché ? Nominatifs ou de service.
Quelqu'un d'autre sait-il ce qu'il fait ? Pas « pourrait deviner » : sait.
Que se passe-t-il s'il s'arrête une semaine ? La réponse donne le niveau de criticité réel, souvent plus élevé qu'on ne le pense.
Un workflow qui dépend d'un processus, branché sur un compte nominatif, connu d'une seule personne, est une panne en attente.
Trois niveaux, trois régimes
| Niveau | Exemple | Régime |
|---|---|---|
| Personnel | trier ses propres messages | libre |
| Équipe | alimenter un tableau partagé | documenté, compte de service |
| Métier | créer des factures, répondre à des clients | inventorié, propriétaire nommé, testé |
Le troisième niveau relève de la même exigence qu'une application interne, quelle que soit la façon dont il a été construit. Le no-code change l'outil de construction, pas la criticité du processus.
L'inventaire minimal
Un tableau partagé, une ligne par workflow, six colonnes : nom, ce qu'il fait, déclencheur, comptes utilisés, propriétaire, dernière vérification.
C'est peu, et cela suffit à répondre à la question qui compte le jour d'un départ : qu'est-ce qui va casser.
Mettez-le à jour lors de la revue trimestrielle, en même temps que le reste.
Le passage de relais
Trois gestes qui évitent l'essentiel des ruptures.
Migrer vers des comptes de service dès qu'un workflow dépasse l'usage personnel.
Nommer un propriétaire, pas un auteur. L'auteur a construit, le propriétaire répond de son fonctionnement aujourd'hui. Ce peut être une autre personne.
Vérifier que quelqu'un d'autre sait l'ouvrir et le modifier. Un accès partagé, et une démonstration de dix minutes.
La question de fin de vie
Un workflow qui ne sert plus doit être désactivé, pas laissé tourner. Il consomme, il peut créer des données incohérentes, et il brouille l'inventaire.
À la revue trimestrielle, la question est simple : à quoi a-t-il servi ce trimestre ? Si la réponse est « rien », désactivez-le, sans le supprimer tout de suite.
À retenir
Un workflow dont dépend un processus n'est plus un outil personnel. Comptes de service, propriétaire nommé, quelqu'un d'autre qui sait l'ouvrir. Un inventaire de six colonnes suffit. Et désactivez ce qui ne sert plus.