Quel est votre rôle chez Eksaé ?

Je m’appelle Médéric Martin et je suis le Directeur technique chez EKSAE. Je suis responsable de la stratégie et de la feuille de route technique et technologique de nos produits. Une de mes principales missions consiste à garantir l’utilisation de produits et de composants techniques toujours à jour, tout en réfléchissant aux moyens de moderniser nos solutions.

Notre stratégie principale consiste à développer tous les composants avec une approche axée sur le Cloud. Depuis quatre ans, nous avons fait converger toutes nos applications vers des plateformes Web compatibles avec le Cloud.

Quelles sont les raisons qui poussent Eksaé à converger vers des plateformes SAAS?

Nous proposons une offre SAAS depuis 2007. Nous avons été les premiers à industrialiser une solution SAAS pour les collectivités et les opérateurs de l’Etat. C’est un besoin de nos clients et c’est un impératif pour les usages actuels d’une solution de gestion.

L’État a choisi de moderniser ses interactions avec les citoyens et les entreprises en adoptant le numérique. Toutes les données seront désormais échangées via le cloud. La plateforme Eksaé fournira à nos utilisateurs un espace dédié sur ce cloud pour collaborer avec toutes les parties prenantes. Elle simplifie considérablement l’expérience utilisateur, car ; de fait, elle nécessite seulement un accès à un navigateur.

L’utilisation d’un environnement en SaaS réduit l’empreinte carbone comparée aux serveurs clients traditionnels. Il est important de noter que, dans le domaine numérique, les principaux responsables de l’empreinte carbone sont les PC, smartphones et autres composants, les centres serveurs venant en troisième position.

De plus en plus, les datacenters, notamment OVH, réutilisent la chaleur émise par les serveurs pour chauffer des réseaux d’eau, alimentant ainsi les bâtiments environnants. Cette méthode présente un aspect vertueux, permettant de réutiliser intelligemment l’énergie qui serait autrement perdue, et contribue à réduire leur empreinte carbone. Par exemple, OVH à Paris utilise la chaleur de son data center pour chauffer une piscine publique, ce qui les place à la pointe de l’efficacité énergétique (PUE).

On pense souvent que ces datacenters sont des désastres écologiques, alors que le véritable problème réside dans l’utilisation des appareils par les utilisateurs eux-mêmes. Eksaé est très sensible à cette question et a fait certifier ses applications cloud par Greenspector. Nous avons obtenu le niveau Silver, le deuxième niveau de sobriété. Nous sommes très satisfaits de ce résultat, fruit de quatre années de travail sur la modernisation de nos offres.

En quoi est-il plus intéressant pour un client de passer au SaaS et de ne pas rester en Insitu ?

Il est important de comprendre que les hyperscaler qui délivrent leurs services dans les data centers disponibles sur le marché, sont des entreprises spécialisées dans l’hébergement et la sécurisation des données, notamment en termes de redondance des moyens électriques, réseaux, matériels. Une simple coupure de courant peut être désastreuse, c’est pourquoi les data centers sont équipés de groupes électrogènes ravitaillés toutes les 24 heures pour garantir le fonctionnement continu des serveurs en cas de panne. Il est évidemment impossible de reproduire dans une collectivité ou un établissement, l’équivalent des services offerts par un hyper-scaler.

Le service informatique d’une collectivité ne dispose pas des ressources nécessaires pour assurer un fonctionnement continu 24h/24 et 7j/7. Cependant, certaines installations du service public doivent être opérationnelles en permanence. Les centres serveurs que nous utilisons possèdent un niveau de certification qui nous permet de proposer un service de haute disponibilité. Il existe différents niveaux d’hébergement, et en France, le niveau le plus élevé est le Tier 3, dont nous disposons chez Eksaé. Nous avons ainsi le plus haut niveau de certification de data center.

Comment cela fonctionne chez Eksaé ?

Notre mission est de garantir le bon fonctionnement des environnements de production de nos clients. Cela implique de veiller à ce que nos niveaux de service respectent les standards du marché, que les environnements de nos clients soient pleinement opérationnels et facilement accessibles.

Il y a plus de deux ans, nous avons remarqué que peu de logiciels offraient des solutions de ‘haute disponibilité’ avec reprise de données. La sécurité est notre priorité absolue. Pour garantir la protection de nos sauvegardes, nous avons pris la décision de les externaliser en dehors de notre site principal. De plus, nous avons renforcé la sécurité des données de nos clients en investissant dans une architecture à deux sites : un site de production principal et un site de production secondaire, distants de plus de 40 kilomètres l’un de l’autre. Cette distance permet de prévenir les risques liés aux catastrophes naturelles, assurant ainsi que si l’un des sites est hors service, l’autre reste opérationnel.

Quelles sont les solutions mises en place en cas de cyberattaque ?

Nous avons choisi de nous appuyer sur deux hébergeurs distincts, en partie pour cette raison. En cas de problème interne, quelle qu’en soit la cause, nous préférons être hébergés par des fournisseurs de données différents.

Cela représente un coût plus élevé, mais c’est un choix que nous avons préféré faire pour offrir une sécurité accrue à nos clients. Depuis un an, nous avons mis en place cette offre de très haute disponibilité. Nous avons acquis du matériel dédié, qui n’est pas utilisé quotidiennement, mais qui est disponible si la situation le nécessite. Le jour où nous en avons besoin, il suffit de l’allumer et de synchroniser pour relancer tous les services. C’est dans ce cadre que nous avons réalisé nos premiers tests PRA/PCA cette année.

En quoi consiste ce test exactement ?

Nous arrêtons la production et basculons sur le site de secours. Il ne s’agit pas simplement de démarrer le site de secours et d’essayer d’y accéder pendant que le site de production est encore en fonctionnement. Pour que le test soit pertinent, il est nécessaire de stopper le site principal, de basculer en suivant scrupuleusement la procédure, et de vérifier que tout fonctionne correctement. Nous effectuons ce test une fois par an et continuerons à le faire à cette fréquence pour garantir que notre PRA est toujours opérationnel et que nos clients bénéficient du niveau de service auquel ils ont souscrit et parce que tout PRA qui n’est pas testé doit être considéré comme non fonctionnel.

Et quels ont été les résultats de ce test ?

Avant tout, il est important de savoir que nous utilisons quotidiennement un outil qui synchronise le site principal avec le site secondaire en quasi-temps réel. Notre site secondaire est donc une réplique du site principal à quelques secondes près.

Lors d’un test PRA, nous interrompons le flux vers le site principal et éteignons toutes les machines virtuelles (VM) une par une. Une fois toutes les machines arrêtées, notre outil prend le relais pour synchroniser toutes les données nécessaires. Une fois la synchronisation terminée, nous redémarrons toutes les VM. Selon nos tests, le temps de reprise est estimé à un maximum de 4 heures.

Cette méthode est très efficace comparée à d’autres systèmes. Sans site secondaire, nous serions soit incapables de restaurer quoi que ce soit, soit obligés de repartir de la dernière sauvegarde, ce qui prendrait plus de temps que 4 heures. C’est souvent le cas des clients In Situ, qui disposent généralement d’un site de production mais rarement d’un site secondaire, en raison du coût d’un site inactif la majeure partie de l’année. Ils ont des sauvegardes, mais en cas de panne matérielle, ils doivent acheter du nouveau matériel et réinstaller toutes les sauvegardes, ce qui entraîne des coûts d’acquisition et des délais de plusieurs mois pour du matériel très spécifique.

En cas de cyberattaque, le site de production est généralement isolé et réquisitionné pour tenter de récupérer le maximum d’informations et de données. Par conséquent, il est peu probable que le matériel attaqué puisse être réutilisé pour une remise en marche : la temporalité n’est pas la même et le risque encouru de réutiliser un système corrompu est trop important.

Ainsi, par rapport à une solution In Situ, ce coût d’acquisition disparaît puisque nous prenons en charge cette partie. La seule responsabilité du client est l’assurance mise en place.

Quelle est la différence entre un PRA (Plan de Reprise d’Activité) et un PCA (Plan de Continuité d’Activité) ?

Notre offre inclut à la fois un PRA (Plan de Reprise d’Activité) et un PCA (Plan de Continuité d’Activité), mais il est important de distinguer les deux. Un PRA définit les procédures nécessaires pour restaurer les outils numériques après un incident.

De leur côté, les clients doivent disposer d’un PCA, qui assure la continuité de leurs activités essentielles, comme le traitement des paies dans un logiciel SIRH, même en cas de panne. Par exemple, si notre PRA n’était pas assez rapide et nécessitait deux mois pour restaurer les systèmes, les clients devraient continuer leurs activités manuellement pendant cette période.

Chez Eksaé, notre objectif est de fournir un PRA complet. En rétablissant les données en moins de 4 heures, nous permettons à nos clients de maintenir leur PCA sans interruption. Ainsi, notre PRA rapide garantit que les clients n’ont pas à se soucier de la continuité de leurs activités, même en l’absence ponctuel de leur service informatique. C’est pourquoi notre offre est un PRA/PCA : le PRA d’Eksaé permet aux clients de bénéficier d’un PCA.

Les collectivités sont-elles vraiment tenues d’avoir un Plan de Continuité d’Activité ?

Les réglementations européennes telles que NIS2 recommandent fortement cette approche. Ces réglementations doivent être mises en œuvre dans tous les pays de l’UE et deviendront bientôt quasi obligatoires.

En cas d’attaque, les sanctions pour ne pas avoir mis en place un PCA varient généralement en fonction du chiffre d’affaires. Cela s’applique aux établissements publics, mais beaucoup moins aux collectivités. C’est pourquoi nous nous concentrons actuellement sur l’accompagnement et la sensibilisation des collectivités à l’importance de mettre en place un PCA.

Est-ce qu’un client qui choisit de rester en In Situ peut mettre en place un PRA ?

Toutes les mairies n’ont pas les moyens de disposer de matériels supplémentaires sur un autre site, prêt à démarrer en cas de besoin.

Si une collectivité souhaite conserver son système principal en interne, nous pouvons également lui proposer un Plan de Continuité d’Activité (PCA).

Concrètement, cela signifie que, quotidiennement, elles transmettent leurs données internes. Chaque jour, nous sauvegardons et exfiltrons leur base de données, élément essentiel de l’application, vers un site sécurisé dédié. En cas de sinistre ou d’attaque, nous sommes capables de leur fournir un système opérationnel en ligne en 4 heures sur notre site principal de production SaaS (ou site secondaire).

A noter que les données sont reçues chiffrées et Eksaé ne peut en aucun cas lire le contenu tant que le client ne nous a pas fourni la clé de déchiffrement. Cela leur permet de bénéficier d’un plan de continuité d’activité tout en restant en interne. Cette solution fait partie de notre offre et est appelée PRA Hybride.

Pour en savoir plus, découvrez notre livre blanc sur la cybersécurité