Salut à tous 
,
Je travaille sur une configuration de sécurité locale pour ma Chrome Extension et mon workflow n8n, et j’aimerais avoir des retours avant de construire la prochaine version et d’écrire le prochain tutoriel.
Voici l’article de référence actuel :
Récemment, j’ai lu l’article d’IBM sur la crypto-agilité :
Crypto-agility and quantum-safe readiness | IBM Quantum Computing Blog
Cela m’a amené à réfléchir à une question simple :
Comment puis-je rendre ma configuration sécurisée actuelle plus facile à faire évoluer plus tard, sans en faire un système crypto d’entreprise surconçu ?
Ma configuration actuelle
Mon projet est volontairement simple :
• une Chrome Extension
• un Native Messaging Host
• un workflow n8n local
• validation des requêtes basée sur HMAC
• protection contre les rejeux avec des vérifications de timestamp / nonce
• limite de confiance locale
• aucun secret exposé dans l’extension
Ce n’est donc pas une plateforme multi-workflow. C’est juste un flux sécurisé local.
Pourquoi je réfléchis à la crypto-agilité
Ma compréhension de la crypto-agilité n’est pas « changer d’algorithmes pour le plaisir ».
Pour moi, cela signifie :
• rendre les choix cryptographiques plus faciles à mettre à jour plus tard,
• éviter la logique de validation codée en dur partout,
• maintenir les futures options de migration ouvertes,
• et être capable de changer les clés ou les détails crypto sans réécrire tout le workflow.
Pour un petit projet local, je ne pense pas que la crypto-agilité complète soit nécessaire.
Ce que j’envisage, c’est une crypto-agilité légère.
Ce que j’entends par « crypto-agilité légère »
Pas une architecture d’entreprise complète.
Pas un sidecar.
Pas une passerelle crypto.
Pas plusieurs fournisseurs d’algorithmes.
Juste une petite amélioration pour rendre la configuration actuelle plus facile à maintenir plus tard.
Cela signifie :
• garder la validation en un seul endroit
• garder les secrets en dehors du code
• ajout optionnel d’un champ kid ou version plus tard
• rendre les futures modifications plus faciles
• éviter la logique crypto répétée
Cela semble être un bon équilibre pour une petite entreprise ou un projet local : une utile amélioration, mais toujours simple.
Ma direction proposée pour la v2.0
Flux actuel
Flux avec crypto-agilité légère
L’objectif n’est pas de créer une complexité supplémentaire.
L’objectif est de rendre la couche de sécurité plus propre et plus facile à faire évoluer plus tard.
Ce sur quoi je veux des retours
Ma question principale est :
Pour une configuration locale une-extension / un-workflow, la crypto-agilité légère a-t-elle du sens, ou c’est déjà trop ?
Je pense que cela vaut la peine de le faire parce que :
• cela apporte une petite amélioration, mais réelle,
• cela maintient l’architecture maintenable,
• et cela évite la surconception.
Mais j’aimerais entendre ce que les autres en pensent avant de construire la v2.0.
Est-ce que cela vous semble être le bon équilibre pour une configuration sécurisée locale ?