Notre infrastructure : Stack de développement 100% Open Source

L'infrastructure que nous utilisons vraiment, et pourquoi nous avons choisi chaque élément

Voici l'infrastructure qui construit, teste et livre chaque module de notre catalogue. Nous la consignons par écrit parce que la question que les agences nous posent le plus souvent prend, sous une forme ou une autre, la tournure suivante : « Êtes-vous une vraie équipe avec une vraie infrastructure, ou trois indépendants réunis sur un Discord ? » La question est légitime. Voici la réponse, vue d'ensemble.

Tout dans notre chaîne de production est open source ou légalement gratuit. Ce n'est pas un positionnement de marque, mais une décision d'achat que nous avons prise il y a des années et que nous n'avons pas eu de raison de revoir. Aucun logiciel piraté, aucune licence crackée, aucun fournisseur propriétaire que nous ne pourrions pas remplacer en un week-end. L'avantage concret : rien dans notre chaîne ne dépend d'une licence que nous pourrions perdre ni d'un SaaS qui pourrait nous verrouiller dehors.

Le serveur

Nous fonctionnons sur du matériel situé dans l'UE et qui nous appartient. Il utilise un stockage à sommes de contrôle, avec mémoire à correction d'erreurs et vérifications d'intégrité régulières. L'hôte est le nôtre ; tout le reste est un conteneur qui s'exécute par-dessus.

Nous avons choisi cette approche de stockage pour une raison bien précise : chaque bloc dispose d'une somme de contrôle, et chaque jeu de données peut être figé en instantané en quelques millisecondes. Ces instantanés sont assez peu coûteux pour que nous en prenions un avant chaque test de mise à niveau de PrestaShop. Quand une migration vers la 9.0 saccage une base de données (c'est arrivé), nous restaurons le jeu de données et le conteneur démarre en quelques secondes dans l'état antérieur à la casse. Cette habitude des instantanés fait qu'une mauvaise migration nous coûte des minutes, pas une journée.

Pourquoi pas un grand cloud public

Une configuration comparable sur un grand cloud public, la mémoire vive, le stockage, la bande passante que consomment nos conteneurs de développement et de pré-production, le trafic sortant pour faire circuler les ZIP et les données de démonstration, coûterait nettement plus cher à exploiter chaque mois. Posséder le matériel maintient une infrastructure à coût fixe, avec des factures prévisibles, plutôt qu'une variable qui nous surprend lorsqu'une démonstration client lance des dizaines de navigateurs en parallèle.

L'autre raison, c'est la juridiction des données. Notre infrastructure est physiquement dans l'UE et sous notre contrôle. Aucune exposition au Cloud Act américain, aucune configuration discrète d'export de journaux que nous aurions oublié de désactiver, aucune surfacturation à la requête sur les e-mails de support que nous envoyons. Pour une petite boutique européenne qui traite avec des marchands européens, c'est le modèle le plus simple, et cela signifie que la conversation de support au sujet de votre boutique, y compris les journaux que vous nous transmettez, reste sur du matériel qui nous appartient.

Des conteneurs dédiés, des images versionnées, chaque version que nous prenons encore en charge

À tout moment, nous faisons tourner un ensemble bien occupé d'environnements à base de conteneurs. Chacun est une installation PrestaShop complète, avec sa propre base de données, son propre utilisateur administrateur, son propre répertoire de modules. Nous maintenons des environnements parallèles pour :

• PrestaShop 1.6.x : ancien, certes, mais des boutiques le font encore tourner et elles continuent d'acheter nos modules.
• PrestaShop 1.7.6 à 1.7.8 : la longue traîne du « on mettra à niveau l'an prochain ».
• PrestaShop 8.1 et 8.2 : la production actuelle pour la majorité des nouvelles boutiques.
• PrestaShop 9.0 et 9.1 : l'avenir chargé en Symfony, où nous concentrons l'essentiel de notre travail de portage cette année.
• Les variantes multiboutique pour chacune des versions ci-dessus. Le multiboutique casse les modules à sa manière bien à lui, et nous ne livrons pas sans l'avoir testé.

Chaque instance PrestaShop reçoit la version de MySQL/MariaDB que cette version attend, plutôt qu'une seule base de données prête-à-porter pour tous. Une couche de cache partagée gère la mise en cache des sessions et des objets pour l'ensemble, reproduisant la manière dont un hébergeur de production configure réellement les choses.

C'est la configuration qui attrape les bugs que vous découvririez sinon en production. Quand un client signale une erreur fatale sur une combinaison plus ancienne de PrestaShop et de base de données avec la mise en cache Smarty forcée, nous avons exactement cette combinaison en marche avant le déjeuner, au lieu d'une unique installation « la plus récente » qui masque discrètement les ruptures propres à une version.

Auto-hébergé, pas du SaaS

Tout ce que nous pouvons raisonnablement héberger, nous l'hébergeons. Sur du matériel situé dans l'UE et qui nous appartient, cela signifie, entre autres :

• Un serveur Git auto-hébergé : chaque dépôt de module réside sur du matériel qui nous appartient, de sorte que la source canonique de chaque version que vous recevez est entre les mains de ceux qui l'écrivent.
• Une pile de messagerie auto-hébergée avec DKIM, SPF et DMARC. Vos réponses de support ne transitent pas par un relais SMTP tiers qui les analyse.
• Un système de documentation interne pour notre base de connaissances et nos runbooks, où un correctif ponctuel devient une procédure reproductible, afin que la personne suivante retrouve la même réponse au lieu de la redécouvrir.
• Un coffre-fort de secrets chiffré pour les identifiants dont notre outillage interne a besoin.
• Une supervision de l'état des services, afin que nous soyons avertis qu'un conteneur est tombé avant que le client ne le soit.
• Un reverse proxy avec SSL automatique sur chaque nom d'hôte interne.
• Un DNS interne, de sorte que les nouveaux environnements de développement apparaissent sur notre réseau privé avec une seule entrée.

L'auto-hébergement représente plus de travail que de glisser une carte bancaire chez un SaaS, et nous en avons conscience. Nous le faisons parce que l'alternative, c'est subir une demi-douzaine de pannes de fournisseurs que nous ne pouvons pas corriger, dispersées dans une pile que nous ne contrôlons pas. Quand quelque chose déraille à 23 h, nous le redémarrons nous-mêmes ; nous n'ouvrons pas un ticket de support pour attendre.

Comment les versions sont construites et revues

La vie d'un module ne s'arrête pas à l'achat, donc l'infrastructure qui le sous-tend non plus. La version qui arrive dans votre back-office est construite à partir de la même source Git auto-hébergée sur laquelle nous développons. Le déploiement est délibérément une action revue par un humain : nos tâches automatisées et nos assistants de codage IA ne publient pas de versions de leur propre chef. Une personne examine la modification avant qu'elle ne devienne une version. Cette étape de revue est le garde-fou qui empêche une modification expérimentale ou un appel de méthode halluciné de se retrouver dans la version que vous installez. L'accès à nos systèmes internes se trouve derrière un accès réseau privé et authentifié plutôt que derrière un port ouvert.

Le poste de développement

Notre machine de développement principale fonctionne sous un environnement Linux moderne et régulièrement mis à jour, nous disposons du dernier PHP, du dernier Node, du dernier tout, sans attendre qu'une distribution le bénisse. Cela compte quand PrestaShop 9 débarque sur PHP 8.2+ et qu'il nous faut le tester dès la semaine où les notes de version paraissent.

Pourquoi Linux côté développement

Parce que la production tourne sous Linux. Systèmes de fichiers sensibles à la casse, permissions POSIX, vrais liens symboliques, tout le tremblement. Nous avons hérité de trop de modules de développeurs sous Windows ou macOS qui fonctionnaient parfaitement sur la machine de l'auteur et cassaient instantanément sur un vrai serveur Linux en hébergement mutualisé, parce que Module.php et module.php sont deux fichiers différents sur l'un et un seul et même fichier sur l'autre. Développer sur la même famille de système d'exploitation que le déploiement retire toute une catégorie de bugs du flux de travail avant qu'ils ne puissent être livrés.

Nous travaillons dans un éditeur open source sans télémétrie de l'éditeur. L'exécution au quotidien repose sur des environnements à base de conteneurs sur le serveur, des conteneurs sans privilège root en local, et des machines virtuelles locales complètes quand nous en avons besoin, généralement pour reproduire l'environnement cPanel ou Plesk d'un client assez fidèlement pour reproduire un bug propre à l'hébergement.

Les assistants de codage IA

L'ajout le plus récent : des assistants de codage IA intégrés au flux de travail quotidien, utiles là où un second regard accélère le travail. Ils s'exécutent contre les mêmes dépôts et les mêmes environnements à base de conteneurs que les humains. Aucun d'eux ne dispose des identifiants permettant de déployer en production. Cela reste une action humaine. Ils prennent en charge la longue traîne du « porte ce contrôleur vers PS 9 », « audite les jetons CSRF manquants », « traduis la formulation du module en néerlandais ». Utilisés avec soin, ils sont un multiplicateur de force. Utilisés sans soin, ils livrent des appels de méthode hallucinés dans une base de code, d'où le maintien d'une étape de revue humaine avant que quoi que ce soit n'atteigne un ZIP de version.

Design et création

Le travail sur les modules ne se résume pas au PHP. Chaque version est livrée avec des icônes, des bannières, des captures d'écran de la boutique, et parfois une police d'icônes sur mesure. Tout est produit avec des outils open source, pour zéro dépense Adobe par an.

Pourquoi cela compte si vous nous achetez un module

Nous testons sur ce que vous utilisez

Votre boutique tourne sous Linux, avec un serveur web, une base de données MySQL/MariaDB, PHP et une couche de cache. Notre environnement de développement repose sur la même pile, pas sur une approximation Windows-avec-WAMP qui se comporte différemment de façons subtiles et pénibles. Quand nous indiquons qu'un module est « testé sur une version donnée de PrestaShop et de base de données avec le cache activé », c'est parce que nous avons littéralement ce conteneur en marche, et non parce que nous avons lu la page des prérequis de PrestaShop.

Nous pouvons reproduire les problèmes sur la version que vous utilisez

Parce que chaque version de PrestaShop prise en charge reste en marche ici, nous ne déboguons pas contre une unique installation « la plus récente » qui masque discrètement les ruptures propres à une version. L'habitude des instantanés nous permet de reproduire une régression sur la version exacte qui l'a provoquée, plutôt que de deviner.

Moins de frais généraux, aucune surfacturation de licences

Zéro dépense pour les factures récurrentes de logiciels propriétaires qu'un atelier de développement classique supporte. C'est un coût récurrent que nous n'avons pas besoin de récupérer dans le prix des modules.

Le même modèle que PrestaShop lui-même

PrestaShop est open source. Vous l'avez choisi pour cette raison. Nous avons choisi notre infrastructure pour la même raison. Quand vous nous achetez un module, vous l'achetez à une équipe qui vit de bout en bout à l'intérieur du modèle open source, pas à une équipe qui vend des modules pour une plateforme ouverte tout en faisant tourner sa propre entreprise sur des outils propriétaires sans lesquels elle ne pourrait pas survivre.

Comment nous en sommes arrivés là

Cette configuration n'est pas née sur un tableau blanc. Chacun de ses éléments a remplacé un élément précédent qui avait échoué de façon mémorable.

Les conteneurs séparés existent parce que nous en avions assez des rapports « ça marche sur ma machine » que nous ne pouvions pas reproduire. Les instantanés de stockage existent parce que nous avons perdu un jour entier, ou presque, à cause d'une migration bâclée de la 1.7 vers la 8, et avons décidé qu'une fois suffisait. La pile de messagerie auto-hébergée existe parce qu'un grand fournisseur de webmail s'est mis à marquer nos réponses de support comme spam assez souvent pour que les clients pensent que nous les ignorions. Le résolveur DNS interne a remplacé un fichier /etc/hosts édité à la main qui cassait chaque fois que quelqu'un ajoutait un nouveau sous-domaine de développement. Le wiki interne a remplacé un tas de fichiers Markdown dans un dépôt que personne ne lisait.

Rien de tout cela n'est théorique. Chaque changement a résolu un problème qui nous avait coûté du temps réel. C'est la seule raison pour laquelle il est resté, et c'est la même raison pour laquelle il tient bon sous les modules que vous utilisez.

Pour aller plus loin

• Notre technologie : la vue plus large à l'échelle de l'entreprise
• Performance Revolution : le module où l'expérience du cache est revenue sous forme de produit
• Renforcement de la sécurité PrestaShop : la même hygiène d'auto-hébergement appliquée à votre boutique
• Index de la base de connaissances : performance, multiboutique, sécurité et bien plus