Votre site est installé sur une distribution Debian Buster avec Nginx/Apache/PHP/MySQL.
Votre site utilise Nginx pour la terminaison SSL, l’objectif consiste à intercaler Varnish entre Apache et Nginx !
L’opération d’installation de Varnish est assez simple. Il faut néanmoins maîtriser la ligne de commande sous Linux et prendre soin de vérifier le bon fonctionnement du cache après installation.
L’objectif, si Nginx redirige les requêtes des ports 80 et 443 vers le port d’écoute Apache (8080 souvent dans ce cas), sera de rediriger les ports 80 et 443 vers le port d’écoute de Varnish, qui par défaut est le 6081. Varnish redirigera à son tour les requêtes sur le port 8080 d’Apache. Le «backend» de Varnish sera le serveur Apache, en localhost sur le port 8080.
Pour installer Varnish sur Debian, il suffit de lancer la commande :
Jusque là, comme Varnish s’installe par défaut sur le port 6081, il n’y a aucun impact sur le Magento !
On prépare la configuration de Varnish qui se trouve dans /etc/varnish/default.vcl.
A noter que cette configuration est fournie par Magento 2 lui même.
Sauvegardez la version d’origine avant de la modifier avec la version à télécharger ici !
Dans ce fichier, il faut vérifier le paragraphe qui définit l’endroit où seront redirigées les requêtes qui arrivent depuis Varnish.
Afin que Nginx redirige les requêtes sur Varnish, il suffit de les envoyer sur le port 6081 au lieu du port 8080.
Dans le fichier de configuration de Nginx, par exemple : /etc/nginx/sites-enabled/reverse-proxy.conf on passe proxy-pass http://localhost:8080 à proxy-pass http://localhost:6081
Le redémarrage de Nginx permet la prise en compte du changement de port :
Une fois Varnish installé, on peut vérifier l‘amélioration des performances.
La première étape consiste à purger le cache de Varnish. Sur le serveur Varnish, il suffit de lancer la commande suivante pour vider toutes les URLs mises en cache :
Le «.» indique 0 et 1 caractère n’importe lequel. Donc toutes les URLs vont matcher cette expression régulière. Toutes les URLs seront donc bannies.
On peut vérifier les temps de réponse avec cUrl. On prépare un fichier pour le formatage des temps de réponse comme suit :
On met Magento en mode debug pour voir les entêtes Varnish. On lance une première requête après le vidage du cache :
On remarque que l’en-tête X-Magento-Cache-Debug vaut MISS.
La page est servie depuis Apache car elle n’était pas disponible au niveau de Varnish. Mais comme cette page a un Max Age d’une journée, elle a vocation a être cachée. Une deuxième requête identique doit montrer que la page est servie du cache de Varnish.
On remarque que l’en-tête X-Magento-Cache-Debug vaut HIT et Varnish a mis la page en cache depuis 70 secondes (entête Age). Ce qui correspond bien à notre première requête !
On vient de diviser le temps de réponse par un facteur 10 !
Si on demande la même page directement depuis Apache, on obtiendrait :
Soit un temps de réponse voisin de celui de Varnish quand la page n’est pas cachée. Ce facteur 10 prouve l’intérêt de Varnish, qui va pouvoir servir tous les contenus statiques, images, JS et CSS et pages également, lorsqu’elles n’ont pas de cookies de session, c’est à dire qu’elle ne dépendent pas de l’utilisateur.
C’est donc un gain pour l’expérience utilisateur autant que pour supporter la charge lors des fortes audiences comme les soldes !
Un système agentique est un système d’IA capable d’exécuter des actions dans un environnement donné pour atteindre un objectif défini. Contrairement à un modèle IA classique qui répond à une question, un agent IA peut enchaîner des étapes, utiliser plusieurs outils et itérer en continu jusqu’à complétion de la tâche.
Un générateur produit du code à partir d’instructions. L’agentic code désigne un système capable d’agir dans un environnement logiciel : analyser un projet, modifier des fichiers, lancer des tests, vérifier les résultats et itérer jusqu’à ce que tout fonctionne.
RAG signifie Retrieval-Augmented Generation. En version classique, un RAG enrichit les réponses d’un modèle IA en lui fournissant des documents de référence. En version agentique, le RAG devient proactif : c’est l’agent lui-même qui décide quelles informations aller chercher, dans quelles sources, et à quel moment de sa tâche. C’est une brique essentielle pour travailler sur des projets logiciels complexes où le contexte est dispersé.
Non. Anthropic note dans son rapport 2026 que les développeurs ne délèguent pleinement que 0 à 20 % de leurs tâches. L’IA est un collaborateur permanent, pas un remplaçant. Le rôle humain reste central pour l’architecture, la conception, la supervision et la qualité.
Parce que les agents IA peuvent accélérer des workflows complets. McKinsey estime une réduction de 20 à 60 % des cycles de relecture. BCG observe que 90 % des CEOs anticipent un ROI mesurable des agents IA dès 2026.
Oui. L’AI Act entré en vigueur en août 2024 encadre l’IA au niveau européen. Les obligations relatives aux systèmes à haut risque s’appliqueront dès août 2026, incluant des exigences de transparence, de traçabilité et de supervision humaine.
Collaborateur toHero
88 % des transformations échouent sur l’adoption (Bain, 2024). Voici comment toHero utilise le design thinking pour remplacer le MVP par le Minimum
66 % des projets IT échouent. Pas à cause du code. À cause d’interfaces que personne n’a testées avant de les construire. Découvrez comment le
Agentic RAG, orchestration des agents IA, conformité réglementaire et AI Act : comment industrialiser l’agentique dans le développement logiciel sur mesure. Épisode 2.