Agents et automatisation (A2)

En bref

Cette offre transforme une tâche répétitive et bien définie en un processus qui s'exécute automatiquement, tout en restant contrôlable par l'équipe du client. Alpene relie les outils existants, traite les informations nécessaires et remet un fonctionnement documenté. Le suivi mensuel associé, appelé suivi C dans le catalogue, veille au bon fonctionnement, accompagne les ajustements d'usage et prend en charge les petites évolutions nécessaires.

Stack de référence de l'offre A2 et de ses options A2.1 à A2.6.

Définition d'un chantier

Un chantier automatise un processus de bout en bout avec :

• un déclencheur ;
• jusqu'à deux sources de données ;
• un traitement IA ;
• une sortie.

Un déclencheur, une source, une étape ou une sortie supplémentaire relève des options A2.1 à A2.3.

Principes

• Un processus est cadré séparément pour chaque service.
• Une automatisation ne remplace pas implicitement une validation humaine importante.
• Les outils existants du client sont utilisés en priorité.
• Les workflows et configurations spécifiques sont réversibles.
• Les données et exécutions de chaque client sont isolées.
• Les choix sont validés par des tests et benchmarks représentatifs.

Architecture de référence

Brique	Référence	Règle
Orchestration visuelle	n8n auto-hébergé	Une instance séparée par client
Alternative code-first	Windmill	Utilisé lorsqu'un chantier repose principalement sur du code
Base d'orchestration	PostgreSQL	Données d'exécution et configuration persistantes
Exécution	Docker	Conteneurs isolés et reproductibles
Secrets	Bitwarden	Aucun secret dans Git ou dans les exports de workflow
Documents bureautiques	AnyDoc	Conversion locale des formats pris en charge vers Markdown
PDF	pdf-inspector	Extraction native et détection des pages nécessitant un OCR
Pages scannées	Mistral OCR	OCR déclenché uniquement lorsque nécessaire
Base vectorielle	PostgreSQL avec pgvector	Référence par défaut
Base vectorielle dédiée	Qdrant	Seulement lorsque le besoin le justifie
Embedding	Mistral Embed	Référence par défaut
Embedding auto-hébergé	multilingual-e5-large	Alternative lorsque l'auto-hébergement est requis
Inférence	Passerelle commune A2 et A3	Quota, jauge et attribution par client et chantier

Orchestration

n8n

n8n est la référence pour les processus composés de connecteurs, déclencheurs et étapes lisibles visuellement.

Chaque client possède une instance ou un périmètre d'exécution séparé avec :

• base PostgreSQL dédiée au périmètre ;
• identifiants propres ;
• sauvegarde quotidienne ;
• supervision ;
• exports de workflows ;
• procédure de mise à jour et de rollback.

Le client utilise une interface métier claire, un canal existant ou l'option A2.5. Il n'accède pas par défaut à l'interface brute de n8n.

Windmill

Windmill est utilisé lorsqu'un chantier est principalement code-first, nécessite des scripts complexes ou bénéficie d'un environnement de développement orienté code.

Un même chantier ne mélange pas n8n et Windmill sans raison technique claire. Ce choix limite les dépendances et simplifie l'exploitation.

Licence n8n

n8n utilise une Sustainable Use License et n'est pas distribué sous une licence open source classique.

Avant commercialisation d'un service fondé sur n8n, Alpene vérifie que :

• la valeur du service ne repose pas principalement sur la revente de n8n ;
• le client ne reçoit pas un accès au produit dans des conditions nécessitant un accord commercial ;
• l'usage prévu reste compatible avec la licence applicable ;
• une licence ou un accord commercial est obtenu si nécessaire.

Point ouvert

• À VALIDER (Baptiste) : confirmer le cadre de licence n8n avant la première commercialisation A2 concernée.

Déclencheurs et interfaces

Les déclencheurs possibles comprennent :

• email dédié ;
• dépôt de fichiers ;
• webhook ;
• planification ;
• événement d'une application ;
• action depuis une interface A2.5.

L'interface client reste adaptée au service. Elle ne doit pas exposer l'outil d'orchestration si l'utilisateur a seulement besoin de déposer une entrée, suivre un statut ou valider un résultat.

Traitement documentaire

La chaîne de référence est :

1. identifier le format ;
2. utiliser pdf-inspector pour un PDF ;
3. extraire directement les pages textuelles ;
4. envoyer uniquement les pages scannées vers Mistral OCR ;
5. utiliser AnyDoc pour les documents bureautiques et autres formats pris en charge ;
6. produire une sortie Markdown structurée ;
7. valider la qualité sur des documents représentatifs du client.

Docling n'est plus la dépendance par défaut. Il peut être testé comme solution de repli lorsqu'un format, une structure ou une qualité d'extraction le justifie.

Le passage à l'OCR n'est pas systématique. Une extraction native correcte est plus simple et évite une consommation inutile.

Base de connaissance (A2.4)

L'option A2.4 ajoute une base documentaire :

1. collecte des documents autorisés ;
2. extraction ;
3. découpage ;
4. calcul des embeddings ;
5. indexation ;
6. recherche ;
7. injection des extraits dans le traitement ;
8. restitution des sources utilisées.

Référence

PostgreSQL avec pgvector est utilisé par défaut afin de limiter le nombre de services à exploiter.

Qdrant est retenu lorsque :

• la volumétrie devient importante ;
• les filtres de métadonnées sont complexes ;
• l'isolation logique doit être renforcée ;
• la performance vectorielle justifie un service dédié ;
• les capacités de pgvector ne suffisent plus au benchmark.

Embedding

Mistral Embed est le modèle d'embedding de référence pour les projets utilisant les services Mistral.

multilingual-e5-large est l'alternative lorsque l'auto-hébergement est nécessaire.

Le modèle d'embedding est versionné. Son remplacement impose :

• benchmark sur un échantillon représentatif ;
• décision explicite ;
• réindexation complète ;
• période de contrôle avant suppression de l'ancien index.

Le modèle de génération peut évoluer sans réindexation si le modèle d'embedding reste inchangé.

Validation humaine

Une validation humaine est conservée lorsqu'une erreur peut :

• engager le client ;
• envoyer une communication externe ;
• modifier une donnée métier importante ;
• déclencher un paiement ou une action irréversible ;
• produire un risque juridique ou de sécurité.

Le workflow présente alors le résultat, sa source et les informations nécessaires à la décision.

Options

A2.1, chantier supplémentaire

Ajoute un processus distinct avec son propre déclencheur, ses données, ses tests et son suivi.

A2.2, connecteur supplémentaire

Ajoute une nouvelle source ou destination avec ses accès, limites, erreurs et procédure de révocation.

A2.3, étape de traitement supplémentaire

Ajoute une transformation ou décision qui dépasse le chantier de base.

A2.4, base de connaissance

Ajoute ingestion, embeddings, indexation, recherche et affichage des sources.

A2.5, interface web dédiée

Ajoute une interface claire pour déposer une entrée, suivre une exécution, valider un résultat ou consulter un historique. Elle suit la stack B2 et peut utiliser le SSO du client.

A2.6, reprise d'historique

Traite un volume existant par lots avec :

• échantillon préalable ;
• estimation de volumétrie ;
• traitement asynchrone ;
• journal des erreurs ;
• reprise sans doublon ;
• contrôle final.

Exploitation

Chaque chantier possède :

• un client_id et un workflow_id stables ;
• métriques de succès, erreur et durée ;
• quota d'inférence ;
• alertes adaptées au service ;
• logs techniques conservés 30 jours ;
• sauvegarde quotidienne ;
• procédure de relance et rollback.

Les prompts, documents et résultats métier ne sont pas placés dans les logs techniques par défaut.

Livraison

Chaque chantier est livré avec :

• description du processus ;
• déclencheurs, entrées et sorties ;
• workflows et scripts spécifiques ;
• configuration non secrète ;
• documentation des connecteurs ;
• tests réalisés ;
• règles de validation humaine ;
• supervision et alertes ;
• sauvegarde et restauration ;
• session de prise en main ;
• deux semaines de rodage.

Réversibilité

À la sortie, le client récupère :

• workflows exportés ;
• scripts et code spécifiques ;
• définitions Docker ;
• données incluses dans le service ;
• sources documentaires ;
• configuration non secrète ;
• documentation des intégrations ;
• procédure de reprise des secrets.

Décisions techniques

Choix	Rationale	Concurrent direct	Pourquoi il n'est pas retenu par défaut
n8n	Nombreux connecteurs et lecture visuelle des processus	Windmill	Plus adapté aux chantiers principalement code-first
AnyDoc	Large couverture documentaire locale avec sortie Markdown	Docling	Plus lourd pour la chaîne de référence, conservé comme solution de repli
Mistral OCR	OCR ciblé pour les pages scannées et documents complexes	Tesseract	Plus simple à auto-héberger mais moins adapté par défaut aux mises en page complexes
PostgreSQL avec pgvector	Mutualise données et recherche vectorielle dans un service connu	Qdrant	Service supplémentaire inutile tant que les besoins restent modérés
Mistral Embed	Cohérence avec la stack Mistral et intégration simple	multilingual-e5-large	Demande une infrastructure d'inférence auto-hébergée

Décisions validées

• n8n est l'orchestrateur visuel de référence, sous réserve de validation de licence.
• Windmill est l'alternative code-first.
• Le client utilise une interface métier claire plutôt que l'interface brute de l'orchestrateur.
• AnyDoc, pdf-inspector et Mistral OCR constituent la chaîne documentaire de référence.
• PostgreSQL avec pgvector est la base vectorielle par défaut.
• Qdrant est réservé aux besoins démontrés par la volumétrie, le filtrage ou les performances.
• Mistral Embed est le modèle d'embedding par défaut.
• multilingual-e5-large est l'alternative auto-hébergée.
• Une validation humaine est maintenue lorsque l'impact métier le nécessite.
• Les workflows, scripts et configurations spécifiques sont remis au client à la sortie.