Connecter plusieurs sites au même ERP : réseau sécurisé et IA documentaire

Dans une entreprise de distribution multisite, le problème apparaît rarement à un seul endroit. Une commande arrive dans la boîte mail commerciale, quelqu'un doit identifier le client et l'agence concernés, l'équipe de ce site doit travailler sur le même ERP que les autres et, ensuite, la direction doit comparer ventes, achats et stocks sur une base commune. Si chaque site est connecté différemment, si le pare-feu a été configuré sans règles communes ou si l'extraction de l'ERP entre en concurrence avec l'activité quotidienne, c'est la technologie qui finit par dicter le rythme de l'entreprise. Chez Congelados Herbania, l'architecture se raconte comme un parcours : protéger les accès avec Fortinet et une segmentation par VLAN ; relier les sites par des tunnels IPsec permanents ; lire Oracle/SIGES en lecture seule avec des chargements incrémentaux toutes les heures ; et placer une application d'IA sur Amazon Bedrock pour lire factures, bons de livraison et commandes. L'objectif n'est pas d'additionner trois projets, mais que le document reçu par e-mail se transforme en travail utile au sein de la même opération.

Le problème n'est pas d'avoir plusieurs sites, mais de fonctionner comme une seule entreprise

Avoir plusieurs sites n'est pas, en soi, un problème technique. Cela le devient lorsque chacun résout les mêmes choses à sa façon et que l'entreprise perd une version unique de son activité.

Une seule activité, plusieurs portes d'entrée

Un client commande par e-mail auprès d'une agence, un autre appelle le siège et un troisième confirme auprès du commercial qui lui rend visite. La commande est le même objet métier, mais elle arrive par des portes différentes. Il en va de même pour les factures fournisseurs : elles arrivent en PDF dans la boîte mail de l'administration, sur papier à l'entrepôt qui réceptionne la marchandise ou agrafées au bon de livraison signé par le transporteur. Si chaque porte d'entrée a son propre circuit, l'entreprise finit par vivre avec autant de versions d'une même commande qu'elle a de sites, et le rapprochement a posteriori devient un travail manuel permanent.

Ce qui doit être unifié et ce qui doit rester séparé

La réponse n'est pas de tout unifier. Ce qui doit être unifié, c'est la logique métier : un seul ERP, un seul référentiel clients et articles, une seule règle de prix et de coût. Ce qui doit rester séparé, c'est le risque : le trafic d'un entrepôt n'a pas à voir le réseau de l'administration, et un ordinateur portable connecté depuis l'extérieur ne devrait pas atteindre les mêmes systèmes qu'un poste de bureau. Unifier l'activité et séparer le réseau sont des décisions complémentaires, pas contradictoires.

Pare-feu périmétrique et segmentation : le socle du réseau

Avant de parler d'ERP, il faut parler de réseau, car tout le reste repose dessus. Le périmètre s'appuie sur un parc Fortinet multi-modèles réparti entre des sites de plusieurs îles et de la péninsule, avec les mêmes règles de configuration partout : c'est le travail que nous décrivons dans pare-feu périmétrique et réseaux multisites.

Fortinet multi-modèles, VLAN et politiques par fonction

Multi-modèles signifie que tous les sites n'ont pas le même équipement, et cela n'aurait pas de sens : une petite agence n'a pas besoin du même pare-feu que le siège. Ce qui est commun, ce sont les règles. Chaque site est segmenté en VLAN selon la fonction du trafic —postes de bureau, entrepôt, équipements réseau, accès invités— et les politiques sont écrites entre fonctions, et non entre machines isolées. Ainsi, une règle se comprend à la lecture de son nom : quelle fonction communique avec quelle fonction, et pourquoi.

Cette discipline a un effet très concret le jour où il faut modifier quelque chose. Lorsqu'un site intègre un nouveau système, inutile de reconstruire le pare-feu : il suffit de décider à quelle fonction il appartient, et il héritera des politiques de cette fonction. Et en cas de problème, la segmentation limite la portée : un poste compromis à l'entrepôt n'atteint pas par défaut les postes de l'administration ni le réseau d'administration des équipements.

Hub-and-spoke : connecter les sites pour travailler sur le même ERP

Une fois le périmètre en place, reste ce qui transforme plusieurs sites en une seule entreprise : que tous travaillent sur le même ERP sans avoir à l'exposer sur Internet.

Des tunnels IPsec permanents entre les sites

La topologie est en étoile (hub-and-spoke) : chaque agence maintient un tunnel IPsec permanent vers le nœud central, où réside l'ERP. Permanent signifie qu'il ne dépend de personne pour être monté : il est établi et se renégocie tout seul. Pour l'utilisateur d'un site, l'ERP se comporte comme s'il était dans la pièce d'à côté : aucune procédure différente parce qu'on se trouve sur une autre île.

Ce mode de connexion a une conséquence souvent négligée : l'ERP n'a pas besoin d'être publié sur Internet. Aucun port ouvert vers l'extérieur ni passerelle supplémentaire à maintenir à jour. L'accès passe par le tunnel ou ne passe pas, et le contrôle reste assuré par le même pare-feu qui gouverne déjà le réseau de chaque site.

Un accès à distance pour ceux qui travaillent à l'extérieur

Les tunnels entre sites couvrent les bureaux, mais pas ceux qui travaillent depuis un hôtel, chez un client ou entre deux visites. Pour eux, il existe un accès à distance par VPN avec une suite cryptographique verrouillée et la confidentialité persistante (Perfect Forward Secrecy), de sorte que la compromission d'une clé de session ne permet pas de déchiffrer les précédentes. C'est une connexion distincte de celle qui relie les sites, avec ses propres politiques, et c'est pourquoi elle est également traitée comme un réseau distinct au sein du pare-feu.

Oracle/SIGES comme ERP commun, sans faire du réseau un goulet d'étranglement

Oracle/SIGES est le système où vivent les achats, les ventes, la facturation et les stocks. Que tous les sites travaillent dessus, c'est l'objectif ; le risque, c'est que ce même système doive aussi servir ceux qui veulent l'analyser. C'est ce partage que nous détaillons dans l'intégration d'Oracle SIGES avec Power BI (en espagnol).

Lecture seule, chargements incrémentaux horaires et PMP

L'extraction se fait en lecture seule. Le processus analytique n'écrit pas dans l'ERP, ne verrouille pas de tables et ne peut modifier aucune donnée opérationnelle : ses droits ne le lui permettent pas. Et on ne relit pas tout à chaque fois. Airflow orchestre des chargements incrémentaux qui récupèrent toutes les heures les nouveaux mouvements, ce qui limite le volume par exécution à une fraction de ce que représenterait une copie complète et évite que l'extraction entre en concurrence avec l'activité quotidienne. Soyons précis : l'information est actualisée toutes les heures, pas en temps réel, et c'est suffisant pour les décisions qui se prennent avec elle.

Le calcul qui demande le plus d'attention est celui du prix moyen pondéré. SIGES le met à jour automatiquement par article et par lot à chaque entrée de marchandise, et tant que les achats sont des achats, le résultat est fiable. Il est faussé dans trois situations connues : les retours clients réintégrés au stock valorisés au prix de vente, les régularisations d'inventaire et les remises rétroactives qui modifient le coût d'un achat déjà enregistré. Savoir que ces trois cas existent permet de les traiter dans la couche analytique, au lieu de les découvrir le jour où la marge ne tombe pas juste.

De l'e-mail à l'ERP : la commande comme nouvelle porte d'entrée opérationnelle

Jusqu'ici, l'architecture permet à une personne de n'importe quel site de travailler sur l'ERP. La limite suivante est d'une autre nature : cette personne doit toujours saisir à la main ce qui arrive écrit dans un document.

Factures, bons de livraison et documents sans modèle par fournisseur

L'application d'IA lit les factures, bons de livraison, devis, commandes et avoirs sans modèle par fournisseur. C'est ce qui la distingue des systèmes de capture classiques : inutile de lui apprendre où se trouve chaque champ dans le format de chaque émetteur, car elle ne travaille pas par position mais par compréhension du document. Un nouveau fournisseur n'impose aucun paramétrage.

De chaque document, elle extrait l'émetteur et le destinataire, avec leur numéro d'identification fiscale (CIF) ; le type de document ; son numéro et sa date ; puis, ligne par ligne, la référence, la désignation, la quantité, l'unité, le prix, la base HT, la TVA et le total. Le résultat est le document converti en données comparables, c'est-à-dire exactement ce que quelqu'un recopiait auparavant à la main.

La commande par e-mail : client, agence, catalogue et réponse

La commande suit son propre parcours, et c'est le seul flux qui s'écrit tout seul dans l'ERP. L'application lit la boîte mail commerciale via Microsoft Graph, identifie le client expéditeur et l'agence concernée, reconnaît les produits demandés à partir du catalogue —même si le client les nomme à sa manière et non comme l'ERP—, enregistre la commande structurée dans Oracle/SIGES et répond depuis la même boîte commerciale. L'e-mail cesse d'être une simple boîte de réception pour devenir une véritable porte d'entrée opérationnelle.

L'IA documentaire s'exécute par-dessus le processus existant

Une décision de conception conditionne tout ce qui précède : l'IA ne remplace pas le processus, elle s'exécute par-dessus. L'ERP reste l'ERP et le circuit de validation reste celui qui existait ; ce qui change, c'est qui fait la lecture. C'est ainsi que nous concevons les applications d'IA documentaire.

Amazon Bedrock dans le compte cloud du client

Le modèle qui lit les documents est Claude Sonnet 4.5, appelé via Amazon Bedrock, et le point important est l'endroit : dans le compte cloud du client lui-même. Les documents ne partent pas vers une plateforme tierce ; l'application appelle le modèle depuis l'infrastructure de l'entreprise, avec ses propres droits et sa propre journalisation.

Techniquement, la lecture se fait directement sur le document. Il n'y a pas d'étape préalable d'OCR qui convertirait l'image en texte et dont dépendraient toutes les erreurs suivantes : le modèle interprète le document tel quel, y compris en corrigeant l'orientation lorsque quelqu'un a scanné une facture de travers ou à l'envers. La différence est mince sur le papier et importante en pratique : une bonne part des erreurs des systèmes de capture classiques naît précisément à ce passage entre l'image et le texte.

Quant aux sorties, rappelons la limite : l'enregistrement automatique dans l'ERP est confirmé pour les commandes. Les autres documents sont livrés sous forme structurée pour être utilisés par le processus qui existait déjà.

Des mouvements de l'ERP à Power BI

Une fois l'activité organisée, reste la dernière question, celle de la direction : comparer ventes, achats et stocks entre sites sur une base commune. C'est cette couche que nous traitons dans entrepôt analytique et Power BI.

Un entrepôt analytique séparé de l'activité

Les mouvements qu'Airflow extrait de l'ERP sont déposés dans un entrepôt analytique construit sur PostgreSQL managé dans AWS Aurora ou sur Snowflake, selon le cas, et les tableaux de bord Power BI sont construits par-dessus. Si cet entrepôt est séparé de l'ERP, ce n'est pas par esthétique : une requête analytique lourde lancée contre la base opérationnelle la ralentit pour tout le monde, et c'est le site qui facture à ce moment-là qui en paie le prix. En les séparant, l'analyse peut être aussi exigeante que nécessaire sans que personne, dans un entrepôt, ne remarque que quelqu'un consulte un rapport.

Le jour où tout va mal fait aussi partie de l'architecture

Une architecture se juge à son comportement en cas de panne. Les configurations des pare-feu sont versionnées : une modification peut être comparée à la précédente et annulée sans rien reconstruire de mémoire. Les postes sont équipés d'un EDR/XDR avec Wazuh, qui surveille les comportements et pas seulement les fichiers connus, et qui centralise les événements de tous les sites au même endroit.

L'identité et la collaboration reposent sur Microsoft 365 avec Teams et Entra ID, et sur Google Workspace là où c'est pertinent, avec les mêmes règles d'accès des deux côtés. Et la messagerie —par où arrivent les commandes, mais aussi la fraude— dispose de SPF, DKIM et DMARC configurés sur le domaine, ce qui empêche un tiers d'écrire au nom de l'entreprise. Ce sont des contrôles peu spectaculaires. Ce sont eux qui font la différence le jour où tout va mal.