Migration d'infrastructure

1. Introduction

Cette réalisation a été effectuée durant ma troisième année de bachelor AIS (administrateur d'infrastructures sécurisées) à l'ESIEA dans le cadre de mon alternance à la coopérative agricole SCA Qualisol. J'ai eu pour mission d'effectuer différentes modifications sur l'infrastructure réseau afin d'améliorer sa disponibilité et sa sécurité.

Durant ce projet, j'ai dû gérer la relation avec plusieurs entreprises partenaires externes pour le transfert de compétences, planifier mes différentes interventions pour limiter l'impact sur l'infrastructure de production et réaliser l'ensemble des configurations pour rendre fonctionnelle cette nouvelle partie de l'infrastructure.

Bien que j'aie travaillé seul à la réalisation, j'étais supervisé par mon maître d'apprentissage, qui était aussi le DSI de l'entreprise. C'est lui qui avait rédigé le cahier des charges, et j'ai dû m'organiser pour mettre en place les besoins exprimés.

2. Le contexte et les besoins

Ce projet est venu après un incident sur le réseau fibre suite à un orage violent dans le secteur du siège social. Cet accès internet du siège étant coupé, aucun de nos sites n'avait d'accès à nos serveurs ou même à internet avant la réparation des lignes. Il est devenu clair qu'il était impossible de ne pas avoir de solution de secours, bien que moins performante que celle initiale, tant nous étions dépendants de cet accès.

Le besoin principal était de changer notre accès internet. Nous avions jusqu'ici un accès internet fibre dédiée classique sans aucun secours. En cas de problème sur la fibre, cela coupait l'accès à internet de tous nos sites, car nous avions un VPN inter-sites où chaque site accédait à internet en passant par notre siège social. Les modifications devaient donc se faire sur l'accès internet de ce siège social.

L'objectif était de mettre en place un secours passant par le réseau 4G sur cet accès internet, ce qui impliquait un changement de routeur et une intervention sur site de notre FAI (Orange).

En plus de ce changement d'accès internet, je devais mettre en place un accès permettant aux employés de se connecter à distance pour le télétravail via la technologie RDS. Nous avions en interne un ERP avec beaucoup de relations avec des bases de données, ce qui rendait impossible l'utilisation d'un VPN classique. Pour cela, je devais mettre en place un serveur de passerelle des services bureau à distance qui allait rediriger les utilisateurs sur un serveur broker faisant office de load-balancer, qui lui-même répartissait les utilisateurs sur l'un des trois serveurs RDS. Ce serveur de passerelle se basant sur une adresse de passerelle qui est un nom de domaine, j'ai dû communiquer avec notre gestionnaire de nom de domaine pour gérer cette adresse de passerelle qui serait un sous-domaine de notre nom de domaine principal.

3. Les objectifs

3.1. Objectifs techniques

• L'amélioration de la sécurité de l'infrastructure
• L'amélioration de la disponibilité de l'infrastructure

3.2. Objectifs non techniques

• Avoir la capacité à s'organiser dans les différentes tâches à faire
• Gérer le relationnel avec les différentes entreprises partenaires

4. Les enjeux et les risques

Enjeu principal : mettre en place ce projet sans impacter les gens de l'entreprise. Étant donné que nous avions déjà des règles en place et que l'ancien accès internet était toujours opérationnel, il fallait trouver le moyen de faire des tests sans impacter l'entreprise mais aussi trouver le moment adéquat pour mettre en production les modifications.

Risques majeurs : Si nous ne faisions pas ces changements, nous risquions de subir la même situation si un événement du même type venait à se reproduire. Pour le changement de serveur passerelle bureau à distance, le risque était de laisser une faille non corrigée par Microsoft, ce qui aurait pu laisser une surface d'attaque plus importante aux pirates.

5. Les différentes étapes du projet

5.1. Cadrage et préparation

Avant de toucher à la moindre configuration, j'ai commencé par cadrer précisément le besoin avec mon maître d'apprentissage et avec les prestataires concernés. Nous avons repris ensemble les incidents passés, les points de fragilité connus et les services qui ne pouvaient absolument pas être interrompus. L'objectif était double : sécuriser la continuité de service du siège et moderniser l'accès distant avec un serveur RDS réinstallé proprement.

Cette phase m'a permis de découper le travail en plusieurs lots, d'identifier les dépendances entre DNS, reverse proxy, passerelle RDS et accès Internet, et de planifier les interventions dans un ordre logique pour éviter toute coupure inutile. J'ai aussi vérifié les contraintes techniques du projet dès le départ, notamment la présence de plusieurs noms de domaine reliés à la même IP publique et l'existence d'un VPN inter-sites qui faisait dépendre l'ensemble des sites du siège. Cette analyse m'a servi de base pour préparer les bascules sans casser l'existant.

5.2. Coordination avec les partenaires

Une fois le cadre posé, j'ai pris contact avec les interlocuteurs externes. Orange intervenait sur la partie accès Internet et bascule 4G, tandis qu'Incomm devait m'accompagner sur la gestion de domaine et la création des sous-domaines nécessaires. Cette coordination était indispensable, car je ne pouvais pas avancer sur la partie technique sans disposer des bons noms de domaine, des bonnes routes réseau et d'un calendrier commun pour les opérations sensibles.

J'ai donc échangé avec chaque partenaire pour clarifier ce qui dépendait de lui, ce qui dépendait de moi et à quel moment chaque action devait être déclenchée. Cela m'a évité de lancer des étapes dans le mauvais ordre et m'a permis de garder une vision complète du projet. J'ai également gardé une trace écrite des échanges pour pouvoir revenir sur les décisions prises et sécuriser le suivi, ce qui est important quand plusieurs acteurs interviennent sur une même infrastructure critique.

5.3. Création d'une passerelle temporaire

Pour ne jamais mettre en danger la passerelle de production pendant les essais, j'ai d'abord demandé la création d'un sous-domaine temporaire auprès du gestionnaire de noms de domaine. Ce sous-domaine m'a servi de point d'entrée isolé pour tester le nouveau serveur sans modifier immédiatement l'adresse utilisée par les utilisateurs.

Cette étape a été importante, car elle m'a permis de travailler dans un environnement intermédiaire. Je pouvais valider la configuration du serveur RDS, les certificats, les redirections et le reverse proxy sans prendre le risque d'affecter le service existant. En pratique, ce sous-domaine temporaire a joué le rôle de zone tampon entre les tests et la production, ce qui m'a donné le temps de corriger les derniers détails avant la bascule réelle.

5.4. Reconstruction du serveur RDS

Le cahier des charges imposait une réinstallation complète plutôt qu'une simple mise à jour du serveur existant. J'ai donc créé une nouvelle machine virtuelle sous Windows Server 2022, puis j'ai reconstruit progressivement la passerelle RDS avec la même logique fonctionnelle que l'ancien serveur. Cette méthode m'a obligé à reprendre les paramètres un à un au lieu de dépendre d'une migration automatique.

J'ai reconfiguré le rôle de passerelle, les éléments liés à l'authentification, les certificats et les paramètres nécessaires pour que le nouveau serveur se comporte exactement comme l'ancien. Le fait de repartir d'une base propre m'a aussi permis de repartir sur une configuration plus saine et plus lisible pour la suite de la maintenance. J'ai pu comparer l'ancien et le nouveau comportement à chaque étape, ce qui m'a évité de reproduire des défauts historiques sans m'en rendre compte.

5.5. Mise en place du routage et des certificats

Comme plusieurs noms de domaine pointaient vers la même adresse publique, j'ai dû mettre en place un reverse proxy capable de distinguer les requêtes selon le nom de domaine utilisé. J'ai créé les règles de routage nécessaires pour que la passerelle temporaire arrive bien sur le nouveau serveur, sans perturber les autres services exposés derrière la même IP.

J'ai également vérifié que les certificats correspondaient bien au nom de domaine utilisé, car une erreur à ce niveau aurait provoqué des alertes côté utilisateurs et aurait dégradé la fiabilité du service. Cette phase était technique, mais elle était surtout critique pour éviter un problème de confiance ou d'accès lors de la mise en production. J'ai passé du temps à tester les chemins de connexion les plus sensibles pour éviter qu'un détail de nommage ne compromette l'ensemble du dispositif.

5.6. Série de tests avant bascule

Avant toute ouverture au reste de l'entreprise, j'ai réalisé plusieurs tests avec la configuration temporaire. J'ai contrôlé les règles de connexion, les droits d'accès, le comportement du serveur selon les profils utilisateurs et la cohérence des certificats. L'objectif était de m'assurer que le nouveau serveur répondait exactement comme l'ancien, mais dans un environnement encore isolé.

J'ai aussi vérifié que les redirections fonctionnaient correctement et qu'aucun détail de configuration ne risquait de bloquer un utilisateur au moment de la bascule. Cette phase de validation m'a permis de repérer les corrections à faire avant de toucher à la production, ce qui a réduit fortement le risque d'incident au moment du passage réel. Chaque test réussi me donnait de la marge pour avancer vers la mise en service avec davantage de confiance.

5.7. Mise en production contrôlée

Une fois les tests validés, j'ai préparé la bascule vers le nouveau serveur. J'ai modifié le reverse proxy pour faire pointer l'adresse de passerelle habituelle vers le nouveau serveur, puis j'ai lancé l'opération un soir en dehors des heures de bureau afin de ne gêner personne. Le choix du créneau était volontaire : il me donnait du temps pour surveiller le comportement du service et réagir immédiatement en cas d'anomalie.

Pendant la mise en production, je suis resté en surveillance active pour vérifier que les connexions passaient bien, que la résolution DNS était correcte et que les utilisateurs auraient bien accès à leur environnement à distance. Une fois les premiers contrôles passés, j'ai pu valider définitivement le nouveau serveur et préparer l'arrêt de l'ancien. Cette présence pendant la bascule m'a permis de réagir tout de suite au moindre écart, plutôt que d'attendre que le problème soit signalé plus tard par les utilisateurs.

5.8. Nettoyage et bascule finale de l'accès Internet

Après la validation du nouveau serveur RDS, j'ai supprimé la configuration temporaire qui avait servi aux essais : l'ancien serveur a été arrêté, la règle de redirection provisoire a été retirée et le sous-domaine temporaire a été supprimé chez le gestionnaire de noms de domaine. Cette étape était importante pour éviter de laisser des éléments inutiles ou confus dans l'infrastructure.

J'ai ensuite enchaîné avec la migration de l'accès Internet en collaboration avec Orange. Là encore, il fallait procéder avec méthode, car le passage sur le secours 4G ne devait pas modifier notre adresse IP publique d'une façon qui casserait les domaines et sous-domaines existants. J'ai donc effectué des vérifications ciblées pendant la migration pour confirmer que les services resteraient joignables sans changement visible pour les utilisateurs. L'objectif n'était pas seulement de faire fonctionner le secours, mais aussi de préserver une continuité perçue comme transparente par les équipes.

5.9. Validation finale et documentation

Tout au long du projet, j'ai consigné les étapes réalisées et fait valider les points clés par mon maître d'apprentissage. Cette documentation n'était pas un simple ajout administratif : elle servait à garder une trace des choix effectués, des réglages appliqués et des vérifications menées, afin que l'infrastructure puisse être comprise et reprise plus facilement par la suite.

La validation finale a consisté à s'assurer que la passerelle RDS, le reverse proxy et le secours 4G fonctionnaient ensemble sans régression. Une fois ce dernier contrôle passé, le projet pouvait être considéré comme terminé, avec une infrastructure plus robuste, une mise en production maîtrisée et une continuité de service réellement renforcée. Cette dernière phase a aussi montré l'importance de laisser derrière soi un système documenté, parce qu'une infrastructure fiable doit pouvoir être reprise même après le départ de son concepteur.

6. Les résultats

6.1. Pour moi

Techniquement, ce projet a grandement renforcé ma maîtrise de l'administration des systèmes Windows et Linux. La configuration complète d'un serveur RDS en production m'a familiarisé avec les certificats numériques, la gestion des accès utilisateurs via Active Directory et les subtilités du reverse proxy. Sur le plan du changement d'accès internet, j'ai compris les enjeux réels de la continuité de service et comment tester une bascule 4G sans impacter les utilisateurs.

Plus largement, ce projet m'a appris que l'administration d'infrastructure n'est pas qu'une question de technique : c'est avant tout une question d'organisation et de planification. J'ai dû anticiper les problèmes, planifier les fenêtres de maintenance hors des heures de travail et assurer une supervision constante lors des passages en production. Cette rigueur dans la gestion de projet m'a permis de livrer une infrastructure zéro downtime malgré la criticité des modifications.

Sur le plan humain, coordonner des partenaires externes (Orange, Incomm) m'a appris à communiquer précisément mes besoins, à fixer des délais réalistes et à résoudre des blocages techniques en collaboration plutôt qu'en tension.

6.2. Pour l'entreprise

La finalisation du projet a permis à la SCA Qualisol d'atteindre deux objectifs critiques : d'une part, l'entreprise dispose désormais d'une continuité de service garantie. Si la fibre venait à être coupée à nouveau, la bascule automatique vers la 4G assurerait qu'aucun utilisateur ne serait impacté. Cela a éliminé un risque stratégique majeur qui aurait pu paralyser l'activité. D'autre part, le déploiement de RDS sécurisé a permis aux employés de travailler en télétravail sans faille de sécurité, ce qui a pris encore plus de sens après la période COVID.

D'un point de vue financier, les modifications apportées ont également optimisé le coût de l'infrastructure. Auparavant, chaque site passait par le siège pour accéder à Internet via le VPN, ce qui générait une latence inutile et une surcharge du lien fibre. Aujourd'hui, avec la redondance en place et une meilleure gestion de la bande passante, l'infrastructure est non seulement plus robuste, mais aussi plus efficace.

7. Ce que je retiens

Ce projet m'a démontré l'importance cruciale de la planification dans les interventions critiques. Mon plus grand apprentissage a été de comprendre que faire des tests préalables en configuration temporaire épargnait des catastrophes lors de la mise en production. J'ai aussi réalisé que la supervision en direct lors des basculements était indispensable : nous avons détecté et résolu une anomalie mineure lors du passage en production RDS grâce à cette vigilance.

Techniquement, mon regard critique porte sur l'absence de documentation pendant le projet. J'ai documenté après coup, ce qui a rendu certains points flous. Si c'était à refaire, j'imposerais une documentation pas à pas au fil de l'eau pour éviter les oublis et faciliter la transmission de la connaissance du système à mes collègues. De plus, je n'avais pas mis en place d'alerte automatisée sur la bascule 4G : une vigilance humaine a suffi, mais une solution de supervision aurait augmenté la résilience globale.

8. Les lendemains du projet

Dans l'immédiat après la mise en production (janvier 2023), j'ai assuré une supervision rapprochée pendant trois semaines pour valider qu'aucune anomalie ne survenait. J'ai documenté l'ensemble de l'infrastructure et formé mon maître d'apprentissage (le DSI) à la gestion des certificats et des règles de reverse proxy, lui permettant de prendre en charge la maintenance future.

À distance, le projet s'est avéré extrêmement stable. Aucune défaillance de la solution RDS n'a été signalée depuis. En ce qui concerne l'accès Internet avec secours 4G, nous n'avons pas eu l'occasion de tester réellement la bascule (pas d'incident fibre depuis janvier 2023), ce qui est un bon signe de la stabilité générale du réseau.

Aujourd'hui, en 2026, l'infrastructure que j'ai mise en place fonctionne toujours sans modification majeure. L'entreprise a cependant initié un projet de migration vers une solution de MDM (Mobile Device Management) pour mieux gérer les accès distants sur tous types de terminaux, ce qui constituera une évolution naturelle et un renforcement de la stratégie de sécurité de l'accès distant dont j'ai posé les bases.