IlyesBesbes

Le client hébergeait son application sur une infrastructure mono-serveur, sans redondance ni visibilité sur les coûts. L'objectif était d'atteindre une disponibilité réelle tout en gardant la facture sous contrôle.

Interventions

• Architecture réseau VPC avec sous-réseaux publics et privés, tables de routage et passerelle NAT.
• Répartition sur deux zones de disponibilité, répartiteur de charge applicatif et Auto Scaling.
• Base de données RDS en réplication synchrone entre les deux zones.
• Politiques IAM au moindre privilège, Security Groups et chiffrement au repos et en transit.
• Sauvegardes automatisées, tests de restauration et bascule DNS avec retour arrière préparé.

Livrables

Dossier d'architecture avec schémas généraux et détaillés, code Terraform, plan de migration, chiffrage des ressources et procédure de bascule.

Applications internes hébergées sur des serveurs physiques vieillissants, déploiements manuels et aucune tolérance aux pannes. Le client voulait moderniser sans confier ses données à un fournisseur public.

Interventions

• Étude des besoins d'hébergement, de disponibilité et de stockage, puis dimensionnement des hyperviseurs.
• Installation d'un cluster Proxmox VE sur plusieurs serveurs physiques.
• Segmentation réseau par VLAN avec un réseau d'administration séparé et des règles de pare-feu.
• Machines virtuelles Debian et Ubuntu, services conteneurisés, configuration automatisée par Ansible.
• Stratégie de sauvegarde et de restauration, supervision des hyperviseurs et des services, tests de bascule.

Livrables

Architecture du cloud privé, inventaire des machines virtuelles, matrice de flux réseau, playbooks Ansible, procédures de sauvegarde et d'administration.

Contraintes de résidence des données sur la production, mais besoin d'élasticité pour les sauvegardes et les services non critiques. L'enjeu était de relier les deux mondes sans créer de faille ni de dépendance fragile.

Interventions

• Analyse des contraintes de résidence et de connectivité, répartition des charges entre interne et AWS.
• Plan d'adressage étudié en amont pour éviter tout recouvrement entre les plages internes et le VPC.
• Tunnel VPN site à site IPsec, règles de routage, pare-feu et résolution DNS commune.
• Architecture d'identité, d'accès et de journalisation partagée entre le datacenter et le cloud.
• Sauvegardes chiffrées vers le stockage objet, supervision de la connectivité et procédures d'incident.

Livrables

Dossier d'architecture hybride, schéma d'interconnexion, matrice des flux, configuration VPN, politique IAM, stratégie de sauvegarde et rapport de tests.

Plusieurs sites et applications dispersés chez des hébergeurs mutualisés, sans sauvegarde fiable ni supervision. Objectif : centraliser, fiabiliser et reprendre la main sur l'exploitation.

Interventions

• Audit des hébergements existants et cartographie des dépendances applicatives.
• Conception de l'architecture cible et migration des applications vers des instances dédiées.
• Migration des bases MySQL et PostgreSQL vers un service managé, avec bascule contrôlée.
• Configuration DNS, certificats TLS et répartition du trafic.
• Supervision des ressources, alertes et plan de retour arrière documenté avant chaque bascule.

Livrables

Cartographie de l'existant, architecture cible, plan de migration par application, procédures de bascule et de retour arrière, tableaux de bord de supervision.

Chaque projet client partait d'une configuration différente, écrite à la main. Les écarts entre environnements provoquaient des incidents à chaque mise en production.

Interventions

• Développement de modules Terraform réutilisables plutôt que du code dupliqué par projet.
• Environnements séparés avec états distants et verrouillage, pour éviter les écritures concurrentes.
• Provisionnement des ressources réseau, calcul et stockage depuis une même base de modules.
• Durcissement des machines Linux par des playbooks Ansible idempotents.
• Validation du plan Terraform et contrôles Checkov dans le pipeline, avant toute application.
• Gestion des variables et des secrets hors du code, via un coffre dédié.

Livrables

Bibliothèque de modules Terraform, configuration des états distants, playbooks Ansible, pipeline de validation, conventions de nommage et documentation de déploiement.

Les développeurs livraient à la main. Les mises en production prenaient une demi-journée et personne ne savait précisément quelle version tournait en production.

Interventions

• Installation et administration de Gitea pour centraliser les dépôts.
• Jenkins avec agents d'exécution dédiés et pipelines décrits en Jenkinsfile versionnés.
• Tests unitaires automatisés et analyse de code SonarQube à chaque intégration.
• Scan des images Docker avec Trivy, bloquant en cas de vulnérabilité critique.
• Publication des images validées dans Nexus, déploiement par Helm avec rolling update.
• Stratégie de rollback documentée et testée, gestion des secrets hors des dépôts.

Livrables

Jenkinsfile versionnés, registre d'artefacts, charts Helm, documentation de livraison et procédure d'incident.

Des microservices à déployer sur des serveurs totalement coupés d'Internet, pour des raisons de cybersécurité. Chaque composant téléchargé automatiquement en temps normal devait être anticipé, validé et transporté.

Interventions

• Étude des contraintes réseau et inventaire complet des dépendances logicielles.
• Préparation des images et des paquets depuis la zone connectée, avec validation par empreinte.
• Registre privé Nexus en zone isolée, devenant la seule source des déploiements.
• Adaptation des charts Helm pour n'utiliser que les registres internes.
• Installation de Kubernetes sans aucune dépendance aux registres publics, automatisée par Ansible.
• Politiques RBAC et NetworkPolicy, tests de mise à jour, de rollback et de restauration en conditions isolées.

Exemple de panne traitée

Une application reste en ImagePullBackOff parce que Kubernetes tente de joindre un registre public injoignable. Diagnostic par inspection des événements du pod, puis import de l'image validée dans Nexus, correction de la référence dans le chart Helm, vérification des imagePullSecrets et relance du déploiement.

Livrables

Bundle d'installation hors ligne, registre privé, playbooks Ansible, charts adaptés, procédure de mise à jour et documentation de sécurité.

Plusieurs applications développées indépendamment, chacune avec son mode d'hébergement. Le client voulait une plateforme unique, standardisée et capable d'encaisser la perte d'un nœud.

Interventions

• Évaluation des besoins applicatifs, des volumes et des contraintes de disponibilité.
• Cluster kubeadm à trois nœuds control plane pour garantir le quorum etcd, et plusieurs workers.
• Réseau de pods Cilium, contrôleur Ingress et gestion des certificats TLS.
• Namespaces, quotas de ressources et comptes de service par application.
• Stockage persistant avec PersistentVolumes et StorageClasses, sauvegardes planifiées.
• Probes de santé, PodDisruptionBudget et tests de perte de worker avant mise en service.

Livrables

Cluster opérationnel, manifests YAML, charts Helm, tableaux de bord de supervision et documentation d'exploitation.

Plateforme fonctionnelle mais permissive : comptes à droits étendus, communication libre entre namespaces, images jamais analysées. L'enjeu était de refermer sans casser la production.

Interventions

• Audit de configuration du cluster avec kube-bench et revue complète des droits d'accès.
• Reprise des rôles IAM et RBAC au principe du moindre privilège, avec matrice des accès.
• NetworkPolicies limitant les communications entre namespaces au strict nécessaire.
• Application des Pod Security Standards et politiques d'admission.
• Analyse des vulnérabilités des images et des manifests, intégrée en étape bloquante de la CI/CD.
• Gestion des secrets applicatifs via un coffre, hors des dépôts et des variables d'environnement.

Livrables

Rapport d'audit, matrice des accès, politiques Kubernetes versionnées, pipeline de sécurité et plan de remédiation priorisé.

Les interruptions étaient découvertes par les utilisateurs avant les équipes techniques. Aucun indicateur partagé, aucune procédure écrite en cas d'incident.

Interventions

• Déploiement de Prometheus et collecte des métriques des nœuds, des pods et des applications.
• Centralisation des journaux applicatifs avec Loki, requêtables depuis la même interface.
• Tableaux de bord Grafana par usage : exploitation, performance applicative, capacité.
• Alertmanager avec des seuils discutés avec les équipes, pour éviter la fatigue d'alerte.
• Définition d'indicateurs SLI et d'objectifs SLO partagés entre technique et métier.
• Probes readiness, liveness et startup, tests de perte de worker et tests de charge.

Livrables

Tableaux de bord, règles d'alerte versionnées, runbooks de diagnostic, rapports de tests de résilience et documentation d'exploitation.

Des opérations récurrentes réalisées à la main par des équipes différentes, avec des résultats variables et aucune trace exploitable en cas de problème.

Interventions

• Développement de scripts Python et Bash pour les tâches d'administration et de maintenance.
• Standardisation des environnements Linux et des images de base.
• Automatisation de la configuration par Ansible, avec des rôles réutilisables entre clients.
• Gestion des variables d'environnement et des secrets applicatifs hors du code.
• Sauvegardes automatiques et procédures de rollback écrites puis testées.

Livrables

Bibliothèque de scripts, rôles Ansible, procédures opérationnelles standardisées et documentation de reprise.

Projets menés de bout en bout, de l'analyse du besoin à la maintenance, en tant que développeur et hébergeur.

Interventions

• Analyse du besoin client et rédaction des spécifications fonctionnelles.
• Développement frontend React et backend Node.js, API REST et authentification sécurisée.
• Conception et gestion des bases de données relationnelles.
• Déploiement sur serveur Linux, configuration NGINX, DNS et certificats TLS.
• Maintenance corrective et évolutive, support technique.

Applications ralenties par des requêtes mal indexées et des bases jamais entretenues depuis leur mise en service.

Interventions

• Administration des bases MySQL et PostgreSQL, en autogéré puis sur service managé.
• Analyse des requêtes lentes, indexation et optimisation des schémas.
• Mise en place des sauvegardes automatiques et tests de restauration réguliers.
• Diagnostic et résolution d'incidents de production.

Parc de serveurs hérités, systèmes non mis à jour et accès partagés entre plusieurs intervenants.

Interventions

• Audit de sécurité des serveurs Linux et des applications hébergées.
• Mise à jour des systèmes et des dépendances, conteneurisation de certains services.
• Durcissement des accès SSH, règles de pare-feu et reverse proxy NGINX.
• Certificats TLS, configuration DNS et surveillance des performances.
• Analyse des journaux applicatifs et documentation des procédures de résolution.

Trois ans d'alternance sur le site de Massy, au support d'une plateforme applicative hébergée sur AWS pour RTE, gestionnaire du réseau de transport d'électricité français. Un contexte d'infrastructure critique, avec des exigences fortes de sécurité, de conformité et de traçabilité.

Interventions

• Support technique de la plateforme : diagnostic et résolution des incidents, suivi des demandes jusqu'à leur clôture.
• Relation directe avec les équipes du client lors de la qualification et de la résolution.
• Correction d'anomalies et amélioration du code applicatif existant.
• Déploiement des correctifs dans les environnements du client.
• Développement de scripts Python et Bash pour fiabiliser et accélérer les tâches récurrentes.

Ce que j'en retire

Travailler sur une infrastructure dont dépend un réseau électrique change la façon d'aborder un changement : on part du principe que ça peut tomber, on limite la portée de chaque modification, et on documente systématiquement. C'est ce réflexe que j'applique aujourd'hui sur mes missions d'architecture.