Risque automatisation no-code : les nouveaux fichiers Excel critiques

Le risque automatisation no-code n’apparaît pas quand une petite ou moyenne entreprise (PME) crée un scénario Make ou un Zap. Il apparaît quand ce workflow devient indispensable à l’outil de gestion de la relation client (CRM), à la facturation, au support ou au reporting sans être traité comme un actif opérationnel.

Pendant longtemps, le risque opérationnel caché des PME avait un visage connu : le fichier Excel critique. Il était envoyé par email, dupliqué, modifié par plusieurs personnes, rempli de formules obscures, de macros non documentées et de règles métier implicites. Personne ne l’appelait système d’information. Pourtant, il calculait des commissions, consolidait le chiffre d’affaires, préparait des exports comptables ou alimentait le reporting de direction.

Aujourd’hui, une partie de ce risque a changé de forme. Il ressemble à un scénario Make créé en urgence, à une automatisation Zapier qui relie un formulaire au CRM, à une base Airtable utilisée comme mini-progiciel de gestion intégré (ERP), à un Google Sheet enrichi par Apps Script ou à un webhook branché sur Stripe, HubSpot, Slack, Notion ou un outil de facturation. Au départ, c’est souvent une excellente initiative. Le problème commence quand ce raccourci devient une dépendance.

Pour les PME françaises et les équipes dans l’Union européenne, le défi est souvent identique : les outils no-code accélèrent le métier et déplacent une partie de la logique système hors du périmètre informatique classique, alors que les exigences — Règlement général sur la protection des données (RGPD), traçabilité, preuve en cas de litige, responsabilité de direction et continuité d’activité après incident — restent comparables à celles d’un composant logiciel traditionnel.

Le risque automatisation no-code commence quand le workflow devient invisible

Une automatisation devient critique lorsqu’elle lit ou modifie des données client, commerciales, financières ou opérationnelles ; lorsqu’elle déclenche une action visible côté client ; lorsqu’elle alimente un CRM, un outil de facturation, un mini-ERP ou un tableau de bord de direction ; ou lorsqu’elle remplace une tâche humaine qui n’est plus contrôlée manuellement.

Le parallèle avec Excel est direct. Les démarches de contrôle parlent souvent d’End-User Computing, c’est-à-dire d’outils créés ou maintenus par les équipes métier en dehors du cadre informatique central, mais utilisés pour décider, calculer ou exécuter des processus importants. Les outils no-code modernes étendent ce phénomène avec plus de connecteurs, plus d’automatisation et parfois plus de données sensibles.

La maturité ne consiste pas à tout recoder. Elle consiste d’abord à nommer correctement ce qui est devenu important. Une automatisation anodine peut rester simple. Une automatisation critique doit être gouvernée.

Le vrai défaut des PME est souvent l’absence d’inventaire

Beaucoup d’entreprises ne savent pas combien de workflows existent, qui les a créés, quels comptes portent les jetons d’accès, quelles données circulent, quels outils sont connectés, quelles règles métier sont encapsulées et ce qui se passe si un traitement échoue. C’est brutal, mais c’est souvent le point faible numéro un : on ne peut pas sécuriser, reprendre ou améliorer ce que personne n’a cartographié.

• Lister les workflows qui touchent au CRM, à la facturation, au support, au reporting, aux relances de paiement, à la création de comptes ou aux exports comptables.
• Identifier le propriétaire métier et le propriétaire technique de chaque workflow.
• Documenter les outils connectés, les données lues, les données modifiées, les droits utilisés et les comptes qui portent les accès.
• Qualifier l’impact d’un échec : visible, silencieux, réversible, client, financier, réglementaire ou opérationnel.
• Décider quoi garder tel quel, documenter, monitorer, durcir, migrer, remplacer ou supprimer.

La fiche minimale d’un workflow no-code critique

Un inventaire utile ne doit pas devenir un exercice bureaucratique. Pour chaque automatisation critique, une fiche courte suffit si elle répond aux bonnes questions : à quoi sert le workflow, qui le possède, quelles données il lit ou écrit, quels outils il relie, quels droits il utilise, quels journaux existent, quelles alertes sont envoyées et quelle reprise est possible si le traitement échoue.

• Nom du workflow, outil utilisé, URL d’administration et environnement concerné.
• Propriétaire métier, propriétaire technique et personne capable d’intervenir en son absence.
• Déclencheur, étapes principales, systèmes connectés et données personnelles ou sensibles manipulées.
• Compte ou jeton utilisé, niveau de droits, date de dernière revue et règle de rotation éventuelle.
• Mode de détection d’échec : journal, notification, alerte, tableau de bord ou contrôle manuel.
• Procédure de reprise : rejouer, corriger, annuler, basculer en manuel ou escalader.

Les erreurs silencieuses coûtent plus cher que les pannes visibles

Une automatisation peut échouer sans bruit. Un jeton d’accès expire. Une interface de programmation change. Un champ CRM est renommé. Une limite de quota est atteinte. Un webhook est appelé deux fois. Un scénario traite deux événements dans le mauvais ordre. Le workflow continue de tourner, mais il produit une donnée fausse, incomplète ou incohérente.

Prenons un exemple simple. Une PME synchronise les demandes entrantes d’un formulaire vers son CRM, puis déclenche un email de qualification et une tâche commerciale. Si le champ “taille d’entreprise” change de nom dans le formulaire, le scénario peut continuer à créer des prospects, mais sans segmenter correctement les comptes. L’équipe ne voit pas une panne ; elle voit, trois semaines plus tard, un pipeline mal priorisé.

Le no-code augmente aussi les risques de données et de sécurité

Une automatisation no-code n’est jamais neutre : elle transporte, transforme, copie, enrichit ou expose de la donnée. Si elle touche des données personnelles, elle peut entrer dans le périmètre du Règlement général sur la protection des données. La CNIL rappelle que le registre des activités de traitement sert notamment à documenter les traitements, les finalités, les catégories de données, les accès, les durées de conservation et les mesures de sécurité.

Le sujet sécurité est tout aussi concret. Un connecteur CRM avec accès lecture-écriture, un jeton administrateur utilisé dans un scénario, un webhook non authentifié, un export automatique vers une base partagée ou une automatisation déclenchée par email peuvent devenir une surface d’attaque. Le fait qu’il n’y ait pas de code écrit à la main ne supprime ni les droits, ni les dépendances, ni les responsabilités.

La bonne cible n’est pas une gouvernance lourde pour chaque micro-automatisation. C’est un niveau de contrôle proportionné au risque : plus le workflow touche un processus vital, plus il doit ressembler à une brique de production.

Quand faut-il durcir, migrer ou supprimer une automatisation ?

La réponse honnête : pas toujours. Certaines automatisations doivent rester dans Make, Zapier, Airtable ou Google Sheets. D’autres doivent être déplacées vers n8n, vers une architecture plus contrôlée ou vers un outil interne. Certaines doivent disparaître, car elles compensent un mauvais processus plutôt qu’elles ne le résolvent.

• Gardez simple si l’impact est faible, la donnée non sensible et la reprise manuelle évidente.
• Durcissez si le workflow est utile, récurrent, dépendant de plusieurs outils et difficile à surveiller.
• Migrez si la logique métier devient complexe, si les volumes augmentent, si les erreurs sont difficiles à rejouer ou si les droits sont trop larges.
• Supprimez si l’automatisation masque une règle obsolète, duplique des données inutiles ou crée plus de confusion que de valeur.

Une approche réaliste : auditer les dix workflows les plus critiques

Les référentiels de résilience opérationnelle utilisés dans les secteurs régulés insistent sur les opérations critiques, les dépendances internes et externes, la continuité d’activité, la gestion des incidents et la capacité de reprise. Une PME n’a pas besoin d’adopter la lourdeur d’une banque. Elle peut en reprendre l’idée utile : savoir quelles opérations sont vitales, de quoi elles dépendent et comment elles reprennent après incident.

Le nouveau fichier Excel critique n’est donc pas seulement un scénario Make ou un Zap oublié. C’est toute logique métier devenue indispensable sans avoir jamais été reconnue comme telle. Avant d’automatiser plus, les PME devraient auditer ce qu’elles ont déjà automatisé : non pour ralentir l’innovation, mais pour éviter que leur système d’exploitation réel soit composé de zones grises que personne ne possède vraiment.