011. Ne jamais hardcoder un token
Les tokens d'API (OpenAI, Stripe, Google) ne doivent jamais se trouver en dur dans un workflow. Utilisez la fonction "connexion" native de Make / n8n / Zapier qui stocke le token chiffré. Si vous partagez un scénario (export JSON), les tokens ne partent pas avec.
Risque : un scénario exporté avec token en clair fuite par erreur. Quelqu'un ouvre, consomme votre compte, le désactive, ou vole des données.
022. Principe du moindre privilège
Chaque connexion API ne doit avoir que les permissions strictement nécessaires. Une connexion "lire Google Sheets" n'a pas besoin de l'accès en écriture sur Drive. Une connexion Gmail "envoyer" n'a pas besoin de lire les emails entrants.
Prenez 5 min à chaque connexion pour cocher uniquement les scopes utiles. Si l'outil ne permet pas ce fin-grain, créez un compte de service dédié.
033. Logs systématiques
Chaque exécution d'un scénario doit laisser une trace. Make conserve 3-7 jours selon le plan. n8n est illimité si auto-hébergé. Zapier conserve 2 semaines en plan payant.
Règle : sur les scénarios critiques (paiement, envoi client, mise à jour base de données), logguez aussi dans un Google Sheet ou un outil externe type Axiom. Sans log pérenne, en cas d'incident, vous ne pouvez ni diagnostiquer ni défendre.
044. Alertes en cas d'anomalie
Configurez des alertes Slack / email pour :
- Scénario en erreur (échec de connexion, timeout)
- Volume anormal (si d'habitude 50 exec/jour, alerte si > 200)
- Consommation anormale (coût tokens IA qui explose)
Make, n8n et Zapier proposent tous ces options en natif. Zéro excuse pour ne pas les activer.
055. Mécanisme de rollback
Si votre automatisation écrit dans un système important (CRM, Sheets, base), prévoyez comment annuler une erreur. Exemples :
- Stocker la version "avant" dans un historique avant modification
- Pouvoir relancer en sens inverse (supprimer les entrées créées entre telle heure et telle heure)
- Tagguer les entrées créées par le workflow pour les distinguer
066. Tests avant mise en production
Avant d'activer un scénario, testez-le sur :
- Un cas nominal (tout va bien)
- Un cas d'erreur (input vide, malformé)
- Un cas limite (caractères spéciaux, accents, grand texte)
Les plateformes permettent des modes "test" ou "sandbox". Utilisez-les. Un scénario mal testé qui part en prod coûte plus cher à corriger qu'il ne rapporte.
077. Conformité RGPD
Toute automatisation qui traite des données personnelles (lead, client, salarié) doit :
- Être basée sur une base légale explicite (consentement, contrat, intérêt légitime)
- N'utiliser que des outils avec DPA signé (voir notre article dédié)
- Respecter la minimisation : ne traiter que les données nécessaires au process
- Être listée dans votre registre des traitements
088. Ownership clair
Chaque workflow a un propriétaire identifié — pas "l'équipe". Son rôle :
- Connaît le scénario et ses dépendances
- Revoit trimestriellement son bon fonctionnement
- Met à jour si un outil externe change (nouveau endpoint, nouveau scope)
- Documente les changements dans un changelog
Sans ownership, les scénarios deviennent des boîtes noires qui plantent 6 mois plus tard sans que personne ne sache pourquoi.