Aller au contenu principal

Articles · Infrastructure

Infrastructure et DevOps : déployer et exploiter en production

Articles sur l'hébergement, Docker, Kubernetes, OpenShift et la CI/CD : déployer sans interruption et dimensionner au plus juste.

À lire en premier

7 articles

Technique · Infrastructure · · 12 min

Dimensionner PHP-FPM sur Kubernetes : le throttling invisible

L'application est lente, les dashboards sont verts et le CPU semble à peine utilisé : c'est la signature du CPU throttling, un phénomène que les graphes de supervision standard ne montrent jamais. Sur une application Symfony déployée sur OpenShift pour un grand opérateur télécom, une seule commande — lire cpu.stat dans le cgroup du pod — a révélé 89 % de fenêtres CPU throttlées et 16 secondes d'attente pour chaque seconde de calcul. Cet article déroule le diagnostic et la correction complète : la limite CPU et le pool PHP-FPM qui se masquaient mutuellement, l'équation mémoire des workers, l'OPcache qui évinçait en boucle et le mpm_prefork imposé en douce par un paquet Debian. Résultat mesuré : 0 % de throttling, sans ajouter un seul nœud au cluster.

Technique · Infrastructure · · 14 min

Déployer en journée sans couper le service

Un déploiement qui exige une coupure de service est un déploiement qu'on repousse — donc rare, donc gros, donc risqué. Sur une application Symfony déployée sur OpenShift pour un grand opérateur télécom, la mise en production se fait désormais en pleine journée, sans aucune interruption, grâce à un rolling update orchestré par GitLab CI et to-be-continuous. Cet article détaille les quatre ingrédients du zero-downtime — replicas, stratégie de bascule, probes honnêtes, attente vérifiée du rollout — et les pièges qui n'apparaissent que lorsque deux versions cohabitent : migrations additives, sessions dans Redis, workers Messenger et CronJobs suspendus. Avec, en bonus, un arbitrage honnête face au blue/green.

Technique · Infrastructure · Développement · · 15 min

Tester l'image Docker de prod avec des e2e en CI

Le container déployé en production n'est jamais exactement le code testé en CI : dépendances sans dev, build des assets, configuration serveur, entrypoint… Sur une application Symfony déployée sur OpenShift pour un grand opérateur télécom, la suite e2e Playwright s'exécute désormais directement contre l'image de production fraîchement construite, comme service GitLab CI, avant toute publication. Cet article détaille l'architecture complète — bundles dev-only pour rendre l'image démarrable en test, dump SQL versionné pour des données déterministes, Mailpit pour les emails — et les pièges concrets rencontrés, dont un TLD préchargé HSTS dans Chromium.

Technique · Architecture · Infrastructure · · 12 min

Webhooks vs polling : intégrations temps réel

Quand deux systèmes doivent communiquer en temps réel, deux approches s'opposent : le polling (interrogation périodique) et les webhooks (notification push). Cet article compare les deux sur des critères concrets — latence, charge serveur, fiabilité, complexité d'implémentation — et détaille l'architecture d'un récepteur de webhooks robuste (idempotence, retry, signature, file d'attente). Il propose une stratégie hybride pour les cas où ni l'un ni l'autre ne suffit seul.

Technique · Sécurité · Infrastructure · · 12 min

Comment sécuriser une application web en production

Les failles de sécurité ne sont pas réservées aux grandes entreprises. Les PME sont des cibles privilégiées car elles investissent moins dans la sécurité applicative. Cet article est un guide pratique pour sécuriser une application web en production : fondations (HTTPS, headers, mises à jour), protection contre les attaques courantes (injection SQL, XSS, CSRF, broken authentication), sécurité infrastructure (moindre privilège, sauvegardes, monitoring) et checklist des 10 points essentiels à vérifier.

Décideurs · Infrastructure · Budget · · 14 min

Cloud vs on-premise : quel hébergement pour une PME

Cloud public ou hébergement dédié ? Pour les PME, ce choix engage la maîtrise des coûts, la souveraineté des données et la capacité d'évolution. Cet article compare les deux modèles sur des critères concrets — TCO sur 3 ans, coûts cachés du cloud (egress, lock-in, facturation complexe), avantages de l'on-premise moderne (coût fixe, performance, RGPD), sécurité et conformité. Il propose une approche hybride pragmatique et une matrice de décision pour faire le bon choix selon le contexte réel de chaque entreprise.

Décideurs · Budget · Infrastructure · · 15 min

Hébergement web : AWS, Azure, OVH ou on-premise ?

Choisir un hébergement est une décision stratégique qui engage coûts, sécurité, conformité et autonomie sur plusieurs années. AWS et Azure offrent puissance et flexibilité, mais au prix d'une complexité et de coûts souvent mal maîtrisés sans pilotage FinOps strict. OVH et l'on-premise restent des alternatives rationnelles selon le contexte, notamment en matière de RGPD et de lisibilité budgétaire. À travers une analyse terrain et un cas réel d'optimisation AWS, cet article propose une grille de lecture pragmatique pour décider sans dépendance ni dérive financière.

À propos de cette sélection

Une application n'a de valeur qu'en production. Ces articles portent sur ce qui la fait tenir : hébergement, conteneurs, Kubernetes et OpenShift, chaînes de CI/CD.

Ils s'appuient sur des incidents et des mesures réelles plutôt que sur la documentation des outils.

Contact

Un sujet vous intéresse ?

Vous avez une question technique ou souhaitez approfondir un sujet abordé dans ces articles ? N'hésitez pas à me contacter pour en discuter.

Me contacter arrow_forward