logo
architecture

Architecture de haute disponibilité

Les environnements de production des sites clients s’appuient sur une architecture de haute disponibilité. Pour cela, plusieurs mécanismes sont utilisés selon le type de composant :

  • Pour ce qui concerne le réseau, routeur, pare-feu… Nous utilisons le “principe du cluster”. C’est un groupe de composants actifs. Si un composant devient défectueux, un autre prend le relais.
  • Pour les composants réalisant les traitements (transactions, traitements par lots, …), nous nous basons sur un “principe de grappe” de serveurs ou de containers sur lesquels sont répartis les utilisateurs, travaux planifiés, transactions, etc.
  • Pour les autres services, on utilise le principe de la redondance des serveurs actifs par des serveurs passifs/inactifs. Ces serveurs sont activés automatiquement en cas de dysfonctionnement d’un composant actif.
réplication

Le principe de réplication

La haute disponibilité des données utilise le principe de la réplication. Nous utilisons une réplication des bases de données en mode asynchrone pour optimiser les performances.
Le délai maximal de pertes de données est de 5 minutes. Pour les répertoires de fichiers, la réplication est synchrone.

sauvegarde

Sauvegarde des données

La haute disponibilité d’une plateforme s’appuie aussi sur le système de sauvegarde des données.

FRÉQUENCE ET RÉTENTION

Tous les serveurs de la plateforme sont sauvegardés selon une “politique de sauvegarde des données” qui concerne :

  • Les journaux des bases de données de production sauvegardés toutes les 5 minutes avec un délai de rétention d’une journée.
  • Tous les espaces de données clients (programmes, bases de données, répertoires de fichiers…). Ils sont sauvegardés quotidiennement avec un délai de rétention de 20 jours.

 

STOCKAGE SUR LES SERVEURS

Les sauvegardes sont stockées dans le centre informatique secondaire situé en Europe. Une copie locale, des 7 derniers jours, est conservée dans le centre de production principal pour des raisons de rapidité de restauration en cas d’incident.

plan de reprise

Plan de reprise d’activité

Le plan de reprise d’activité (PRA) permet d’assurer la continuité des services. Il est déclenché en cas de menace ou de sinistre affectant la plateforme Cloud hébergée dans le data center principal. Le PRA s’appuie sur le data center secondaire.

Dans ce centre informatique, les accès réseau sont préconfigurés. Les zones de stockages de données sont alimentées par synchronisations régulières des données du site principal. Nous estimons la durée maximale des pertes de données à 15 minutes.

Quand le PRA est déclenché, une mise en route progressive et automatisée des composants est effectuée pour les services de traitement.

Le délai de mise en service du centre informatique de secours s’appuie sur un redémarrage progressif des services. Cela se passe 4 heures après la décision de basculer sur le centre informatique de secours. Nous estimons un délai de 24 heures pour bénéficier des pleines capacités de production de la plateforme.

Cet article vous a plu ? Partagez-le !

Les dernières actualités de la gestion d’entreprise

ERP 20 Avr 2026
Tarifs de vente : comment votre ERP les maintient à jour quand les prix s’emballent

Les prix de vos fournisseurs sont instables. Parfois chaque semaine. Parfois chaque jour.  Et pendant ce temps, vos équipes commerciales continuent de vendre sur des tarifs qui ne reflètent plus la réalité de vos coûts d’achat. Résultat : vos marges fondent sans que personne ne s’en aperçoive immédiatement.  C’est un problème qui touche tous les secteurs. Un industriel qui vend des pièces usinées, un prestataire de maintenance qui facture des interventions avec fournitures, un distributeur qui gère des milliers de références : tous subissent le même décalage entre ce que coûte réellement un produit ou une prestation, et ce qui est facturé au client.   Ce décalage, c’est de la marge perdue. Silencieusement, commande après commande.  Alors comment y mettre fin ? En comprenant ce que votre ERP peut faire pour vous — et en activant les bons mécanismes. 

IA 15 Avr 2026
SLM vs LLM : quel modèle d’IA pour vos futurs agents intelligents ?

L’intelligence artificielle entre dans une nouvelle ère : celle des agents IA autonomes, capables de planifier, d’exécuter et d’optimiser des tâches complexes sans intervention humaine constante. Selon Gartner, d’ici 2028, 33 % des applications d’entreprise intégreront des fonctionnalités agentiques, contre moins de 1 % début 2024. Mais derrière chaque agent se cache un choix technique structurant : quel modèle de langage le fait tourner ? Un LLM (Large Language Model) ou un SLM (Small Language Model) ? Ce choix a des conséquences directes sur les coûts, la rapidité, la fiabilité et la pertinence des réponses. Décryptage pour y voir clair. 

Métier 13 Avr 2026
Le vrai problème de la maintenance industrielle n’est pas technique (et personne n’en parle)
IA 09 Avr 2026
Plateforme multi-agents IA : orchestrer des IA agentiques pour l’entreprise
Société 02 Avr 2026
Revivez les temps forts de notre événement « Signature » !

Envie de rester informé ? Recevez nos actualités dans votre boîte email.