Architecture & fiabilité
Des systèmes conçus pour les jours où tout ne se passe pas bien.
Un flux qui fonctionne en démonstration n’est pas un système de production. Voici les principes d’architecture que nous appliquons pour qu’une automatisation reste fiable, compréhensible et reprenable.
- Pour qui
- Responsables IT, opérations et direction technique.
- Principe
- Chaque brique fait un seul travail et peut être remplacée.
- Réversibilité
- Vos règles et vos données restent documentées et exportables.
Architecture de référence
Des responsabilités séparées, lisibles et testables.
Chaque projet est adapté, mais la structure reste la même. Un flux simple n’utilise que les couches nécessaires.
- 01EntréesE-mail, fichiers, formulaires, API, webhooks, tâches planifiées. L’entrée brute est conservée pour pouvoir rejouer un traitement.
- 02ValidationFormat, champs obligatoires, doublons. Les pièces jointes sont isolées avant toute lecture.
- 03OrchestrationFiles d’attente, états, reprises et délais. Un traitement interrompu reprend là où il s’est arrêté.
- 04Règles métierPrix, seuils, routage, contrôles : tout ce qui doit être exact est écrit en code lisible et testé.
- 05IA, si utile IAClassification, extraction, recherche documentaire. Sorties vérifiées par un schéma, niveau de confiance par résultat.
- 06Contrôle humain HumainValidation avant toute action engageante, et pour chaque cas sous le seuil de confiance.
- 07ActionsÉcriture dans l’ERP, le CRM, la messagerie ou une base de données, avec des droits minimaux.
Principes de fiabilité
Ce que nous appliquons par défaut.
Ces principes ne sont pas des options facturées en supplément : ils font partie de la manière dont nous construisons.
Validation des entrées
Les données reçues sont contrôlées (format, champs obligatoires, cohérence) avant tout traitement. Une entrée invalide part vers une file humaine au lieu de se propager.
Idempotence
Chaque opération porte une clé unique : la rejouer ne produit aucun effet supplémentaire. Pas de double facture, de double commande ni de double envoi.
Reprises maîtrisées
Un échec temporaire est relancé automatiquement, à intervalles croissants et avec un nombre maximal de tentatives, puis signalé.
Délais et solutions de repli
Chaque appel externe a un délai maximal. Au-delà, un comportement prévu s’applique : mise en attente, transmission à une personne, alerte.
Résultat incertain
Lorsqu’on ne sait pas si une action a abouti, par exemple après une coupure réseau, elle est marquée comme incertaine et vérifiée, jamais relancée à l’aveugle.
Journal d’audit
Qui, quoi, quand, sur quelle donnée, avec quel résultat. Le journal fonctionne en ajout seul : ses entrées ne sont ni modifiées ni supprimées.
Moindre privilège
Chaque composant reçoit uniquement les droits nécessaires. Les secrets restent côté serveur, jamais dans un navigateur ni dans le code source.
Isolation
Les traitements à risque, comme l’analyse de fichiers reçus, s’exécutent dans un environnement isolé, sans accès réseau ni accès au reste du système.
Environnements séparés
Développement, test et production sont distincts. Aucun test sur vos données de production sans votre accord.
Mode observation
Un nouveau flux peut d’abord fonctionner sans rien envoyer : il prépare chaque action pour vérification, le temps de valider son comportement réel.
Arrêt d’urgence
Chaque flux peut être suspendu sans perdre les éléments en attente, puis repris proprement.
Technologies
Choisies selon le problème, jamais imposées.
Nous privilégions des technologies éprouvées, documentées et remplaçables.
- Orchestration
- Code Node.js ou Python, n8n lorsqu’il est adapté, files d’attente et tâches planifiées.
- Données
- PostgreSQL, SQLite ou vos bases existantes ; sauvegardes chiffrées.
- IA
- Modèles de fournisseurs établis ou modèles ouverts installés localement ; recherche vectorielle pour les documents.
- Hébergement
- Serveurs Linux, conteneurs, cloud privé ou votre infrastructure.
- Observabilité
- Journaux structurés, métriques, alertes par e-mail ou messagerie.
Réversibilité
Votre actif, ce sont vos règles et vos données, pas l’outil.
Les règles métier, les interfaces et les données restent documentées et exportables. Un modèle d’IA ou un composant peut être remplacé sans reconstruire le processus, et le système peut être repris par une autre équipe.
Architecture
Commencer simple, ajouter seulement ce qui manque.
Parlons de votre processus et du niveau de fiabilité qu’il exige réellement.