Nos outils et technologies.

Voici, en détail, les outils que nous maîtrisons et dont nous nous servons pour vos projets comme pour les nôtres.

Nous ne partons pas d’une technologie préférée. Quand le standard suffit — un site vitrine, une boutique en ligne classique —, un CMS comme WordPress fait le travail pour moins cher. Quand il ne suffit plus, nous développons sur mesure, et le choix du langage dépend de ce que l’application devra supporter : la charge, la durée de vie, l’équipe qui la reprendra.

Langages et frameworks

Node.js

Moteur permettant d’exécuter du JavaScript et du TypeScript côté serveur. Nous nous en servons principalement sur les projets qui doivent traiter un nombre important de requêtes simultanées.

Comme PHP, il permet de créer des sites, des applications et des boutiques en ligne. On le trouve souvent dans la mouvance des CMS headless, que nous avons également adoptée.

Bun

Environnement d’exécution JavaScript et TypeScript, alternative à Node.js. Là où un projet Node.js assemble plusieurs outils, Bun en réunit l’essentiel en un seul exécutable : il exécute le code, TypeScript compris sans étape de compilation, installe les dépendances, regroupe les fichiers et lance les tests. L’installation des dépendances et le démarrage y sont nettement plus rapides.

Il reprend l’essentiel des API de Node.js : la plupart des applications et des paquets npm fonctionnent sans modification. Ce site en est un exemple — ses dépendances sont installées et le site construit par Bun, dans notre chaîne d’intégration continue, et c’est encore Bun qui le sert en production, dans son conteneur.

PHP

Langage de script sur lequel reposent WordPress, Drupal et WooCommerce. Il permet de réaliser des boutiques en ligne, des sites vitrines et des applications destinées à des clients ou à des collaborateurs — extranets et intranets.

Symfony

Le framework PHP mondialement connu, largement utilisé par la communauté. Nous nous en servons ponctuellement, quand le besoin le justifie — souvent pour des extranets et des intranets destinés à des clients qui veulent rester sur PHP, pour l’économie que cela représente à l’hébergement.

Nous réalisons alors le back en PHP avec Symfony et toute sa panoplie d’outils, et le front sous forme d’application exécutée par le navigateur, en JavaScript ou TypeScript — ce qui n’engage aucune ressource serveur pour l’affichage et l’interaction.

Kotlin et Java

Le support des coroutines par Kotlin nous permet de réaliser des applications web solides, avec des API REST, gRPC ou GraphQL. Des frameworks comme Micronaut ou Spring donnent rapidement des applications fiables, capables d’absorber la majorité des charges, avec une syntaxe qui évite d’écrire du code superflu.

Nous apprécions particulièrement d’obtenir un seul livrable capable de fonctionner sur de nombreux systèmes d’exploitation. Au besoin, la compilation native via GraalVM et Native Image produit un binaire optimisé.

Micronaut

Framework Kotlin et Java pensé pour les microservices et les API REST, gRPC ou GraphQL. Sa particularité : il résout l’injection de dépendances à la compilation, et non au démarrage de l’application. Une erreur de câblage qui ferait tomber le service au lancement est signalée dès la construction, sur le poste du développeur plutôt qu’en production.

Il en découle un démarrage rapide et une empreinte mémoire réduite, deux qualités qui comptent quand les services sont petits et nombreux. C’est aussi ce qui le rend bien adapté à la compilation native avec GraalVM.

Développement Micronaut · Hébergement Micronaut

Spring Boot

Principalement utilisé pour nos outils internes de gestion. Nous y apprécions la facilité avec laquelle on crée des API REST et GraphQL, tout en profitant de l’écosystème Kotlin et Java. Ses points forts à nos yeux : l’ORM Hibernate et la gestion de sources de données multiples.

C’est le framework de la plateforme Java le plus répandu : une application Spring Boot se reprend facilement, par nous comme par une autre équipe, et trouve une bibliothèque pour presque chaque besoin.

À l’hébergement, une application Spring Boot ne se dimensionne pas comme un site PHP : c’est la mémoire qui décide, bien plus que le disque ou le nombre de visites. C’est la première chose que nous regardons. Développement Spring Boot · Hébergement Spring Boot

Go

Nous utilisons principalement ce langage pour produire des binaires autonomes, dédiés à une tâche précise et capables de tenir la charge. Ce sont le plus souvent des services réseau.

Nous nous en servons aujourd’hui pour notre outil de redirection HTTP, un outil de vérification de la présence d’adresses IP dans des listes noires, une application d’identification des botnets qui nous attaquent en SSH, et nos serveurs SMTP entrants et sortants.

FastAPI

Un framework web moderne et rapide pour construire des API en Python, reposant sur les standards ASGI pour l’asynchronisme. Il combine des performances proches de Node.js et Go — grâce à Starlette pour le routage et Pydantic pour la validation — avec une documentation interactive générée automatiquement.

Son architecture asynchrone le rend particulièrement adapté aux microservices, aux applications de l’internet des objets et aux systèmes qui doivent traiter beaucoup de requêtes simultanées.

API

L’API est le contrat entre votre application et ce qui la consomme : une interface web, une application mobile, un partenaire, un autre service. Nous exposons nos applications en REST, gRPC ou GraphQL — en Symfony, Python, Java, Kotlin, Go ou Node.js —, et le choix dépend de qui la consomme et de la manière dont il le fait. Une même application peut d’ailleurs en proposer plusieurs. Application mobile

REST

Le style d’API le plus répandu. Chaque ressource — un client, une commande, une facture — a son adresse, et les verbes du protocole HTTP disent ce qu’on en fait : lire, créer, modifier, supprimer. Les échanges se font le plus souvent en JSON.

Sa force est d’être compris partout : n’importe quel langage, outil ou partenaire sait l’appeler, et les caches HTTP habituels s’appliquent aux lectures. C’est le choix naturel pour une API publique ou ouverte à des partenaires, qui se documente au format OpenAPI. Sa limite : un écran qui assemble beaucoup de données peut demander plusieurs appels successifs.

gRPC

Protocole binaire conçu pour les échanges entre services. Le contrat est écrit une fois, dans un fichier Protocol Buffers, et le code client comme le code serveur en sont générés, dans chaque langage : les deux côtés partagent le même contrat typé, plutôt qu’une documentation qu’on espère à jour.

Les messages sont compacts et transitent sur HTTP/2, ce qui le rend nettement plus rapide que du JSON, et il permet des flux continus dans les deux sens. C’est l’outil des microservices qui se parlent beaucoup, par exemple avec Micronaut. Il n’est en revanche pas appelable directement depuis un navigateur : pour une interface web, on lui préfère REST ou GraphQL.

GraphQL

Ici, c’est le client qui décrit exactement les données dont il a besoin, dans une seule requête, et le serveur renvoie cela et rien d’autre. Le schéma est typé et documente l’API de lui-même.

Il convient particulièrement aux interfaces — application front, application mobile — dont chaque écran assemble des données venues de plusieurs endroits : un seul aller-retour au lieu de plusieurs, et une interface qui évolue sans attendre une nouvelle version de l’API. La contrepartie se gère côté serveur : borner le coût des requêtes, pour qu’une requête trop gourmande ne puisse pas mettre le service à genoux. Application front SPA

Méthodes de développement

Ces approches servent les applications appelées à durer et à changer de mains. Nous les employons quand le métier le justifie, et pas ailleurs : appliquées partout, elles produisent trois fois plus de code pour le même résultat. Nous commençons simple, et les introduisons là où la complexité l’exige — souvent sur un seul domaine de l’application.

Développement orienté domaine (DDD)

Le Domain-Driven Design tient dans une exigence : le code doit parler la même langue que vous. Si vos équipes disent « dossier », « avenant » et « relance », ces mots se retrouvent tels quels dans le code. Un code qui emploie vos mots se relit avec vous, et une règle métier qui change se retrouve à un seul endroit.

Nous passons donc du temps avec ceux qui font le métier, pas seulement avec ceux qui commandent le projet, et nous découpons l’application en domaines cohérents : la facturation et le suivi de production ne parlent pas de la même chose, même quand ils emploient tous deux le mot « commande ».

Deux briques en découlent. Les Value Objects rendent l’invalide impossible : un IBAN, un SIRET ou un montant sont des types dédiés, qui ne peuvent pas exister s’ils ne sont pas valides. Et l’architecture hexagonale place le métier au centre : il ne dépend ni du framework, ni de la base de données. Ses règles se testent sans serveur, et passer de MariaDB à PostgreSQL ne touche que l’adaptateur, pas le cœur. Applications métier · Architecture du SI

Développement piloté par les tests (TDD)

Tout le monde dit tester son code. Le Test-Driven Development impose une contrainte réelle : le test s’écrit avant l’implémentation. Il échoue, on écrit le minimum de code qui le fait passer, puis on range.

Le bénéfice n’est pas tant la couverture obtenue que l’ordre des questions : écrire le test d’abord oblige à formuler ce que le code doit faire avant de décider comment il le fera. Un test écrit après coup valide ce que le code fait, erreurs comprises ; un test écrit avant décrit ce qu’on attend de lui. Et du code écrit ainsi est testable par construction : aucune règle métier ne finit enfouie là où on ne peut l’éprouver.

Développement piloté par le comportement (BDD)

Le Behaviour-Driven Development prolonge le TDD vers le métier. Avant d’écrire le code, on décrit le comportement attendu sous forme de scénarios, dans des phrases que les personnes du métier lisent et valident elles-mêmes :

Étant donné une facture échue depuis 30 jours
Quand la relance automatique s’exécute
Alors le client reçoit un premier rappel

Ces scénarios sont ensuite exécutés comme des tests automatisés, avec des outils comme Cucumber. Ils deviennent une documentation qui ne peut pas mentir : si le comportement change sans que le scénario suive, les tests échouent. Le BDD rejoint ainsi le DDD — les scénarios emploient le vocabulaire du métier — et le TDD, qui prend le relais pour le détail de l’implémentation.

Sites et interfaces

WordPress

Le CMS le plus utilisé au monde, et celui que nous proposons le plus souvent pour un site vitrine ou un blog : l’interface d’administration est connue, les extensions couvrent la plupart des besoins, et le site reste modifiable sans nous. Associé à WooCommerce, il devient une boutique en ligne.

Nous avons par exemple passé Jacques André Éditeur sous WordPress et WooCommerce, depuis une solution propriétaire, en conservant son paiement Systempay, ou installateurgpl.com sous WordPress.

Sa popularité a un revers : c’est aussi le CMS le plus attaqué. Nous l’hébergeons avec un pare-feu applicatif, une sauvegarde quotidienne conservée 30 jours et le cache LiteSpeed. Création de site WordPress · Hébergement WordPress

WooCommerce

Extension qui transforme un site WordPress en boutique en ligne : catalogue, panier, paiement et livraison se gèrent dans la même interface d’administration que le reste du site. Face à PrestaShop ou Magento, le choix se fait sur votre catalogue et votre façon de le gérer, pas sur la mode.

Nous mettons WooCommerce en place et adaptons votre thème. Si votre banque est le CIC ou le Crédit Mutuel, nous fournissons gracieusement notre extension Monetico, développée en interne ; sinon nous utilisons le module fourni par votre banque, et s’il n’existe pas, nous le développons. Quand le catalogue vient d’une autre boutique, nous écrivons les programmes qui vont chercher les produits et les réintègrent. Développement WordPress · Boutique en ligne

React

Une bibliothèque d’interface, pas un framework de site. Son terrain, c’est l’écran complexe — un back-office, un configurateur, un tableau de bord —, pas forcément le site entier.

Une interface React construite dans le navigateur n’est pas simplement indexable par les moteurs de recherche. Pour un espace connecté, la question ne se pose pas ; pour des pages publiques, elle décide de l’architecture, et la réponse s’appelle alors Next.js.

C’est aussi la bibliothèque d’interface la plus répandue : le vivier de développeurs est large, et vos équipes ont des chances de la pratiquer. C’est un argument de reprise, qui pèse souvent plus lourd que les mérites techniques. Développement React

Next.js

Framework React capable de construire une page au moment de la demande, sur le serveur. C’est ce qu’il faut pour un espace client, un tableau de bord ou toute application dont le contenu n’existe pas avant la visite.

Il sait aussi générer des pages à l’avance, ou les régénérer à intervalles réguliers. Le choix se fait page par page, et il pèse autant sur la facture d’hébergement que sur l’architecture : une page identique pour tous les visiteurs n’a pas à être recalculée à chaque appel.

Nous le retenons quand React s’impose — une équipe qui le connaît déjà, une forte part applicative, un existant en React. Pour un site essentiellement éditorial, Astro fait souvent mieux, et plus léger. Développement Next.js · Hébergement Next.js

Vue.js

Vue s’adopte par morceaux : on peut l’ajouter à une seule page d’un site existant, sans toucher au reste. C’est ce qui le distingue le plus nettement des autres bibliothèques d’interface, et ce qui permet de moderniser un écran sans tout réécrire.

Ce site en est un exemple. La demande de rappel et le formulaire de contact sont des composants Vue, chargés seulement là où ils servent ; le reste des pages n’en charge pas. Quand l’interface devient le site entier et doit être indexée, l’outil s’appelle alors Nuxt.

Sa documentation est réputée abordable, et le transmettre à une équipe qui ne le pratique pas encore demande moins d’effort que ses concurrents. Développement Vue.js · Développement Nuxt

Svelte

Svelte compile vos composants en JavaScript ordinaire au moment de la construction. Le navigateur ne reçoit donc aucun moteur d’interface, seulement le code de l’écran : ce sont les interfaces les plus légères à charger, ce qui compte sur mobile et sur les connexions lentes.

La contrepartie est humaine : le vivier de développeurs Svelte est nettement plus étroit que celui de React ou de Vue, et la question de savoir qui reprendra le code se pose avec plus d’acuité. Pour des pages publiques, qui demandent un rendu côté serveur, l’outil s’appelle SvelteKit. Développement Svelte

SvelteKit

SvelteKit apporte à Svelte ce qui lui manque pour faire un site : le routage, le rendu côté serveur et le chargement des données, sans renvoyer de moteur d’interface au navigateur. Le mode de rendu — généré à l’avance ou calculé à la demande — se décide page par page.

Comme Next.js et Nuxt, son exécution demande un environnement JavaScript côté serveur. Nous l’hébergeons sur notre propre infrastructure, en France : rien n’oblige à passer par la plateforme d’un éditeur. Développement SvelteKit

Astro

Son nom ne vous dit peut-être rien, mais il compte beaucoup pour nous — ce site en est fait. Dans la mouvance des CMS headless, nous l’employons souvent, en particulier sur les projets de taille modeste. Son intérêt principal est de combiner plusieurs frameworks JavaScript : React, Svelte, Vue.js ou Alpine.js.

Chaque morceau de page prend vie grâce au framework avec lequel son composant a été écrit, et chaque page peut être générée en statique — d’où une vitesse d’exécution considérable sans consommer de processeur ni de mémoire. Autre bénéfice : cela rend l’attaque du site nettement plus difficile.

Le framework prend également en charge les optimisations les plus poussées, celles qui permettent d’atteindre les meilleurs scores Lighthouse.

Ce n’est pas pour rien que Porsche, NordVPN ou The Guardian l’utilisent.

Gatsby

Framework headless fondé sur React. Nous nous en servons pour des blogs et des sites e-commerce. Comme Astro, il génère des pages statiques, d’où une consultation très rapide.

Son point fort : il se branche facilement sur WordPress, dont il récupère alors la gestion de contenu et l’interface d’administration.

Bases de données

MariaDB

La base relationnelle de la plupart des sites et des applications PHP, WordPress compris. Elle est disponible sur tous nos hébergements mutualisés.

Pour les services qui ne doivent pas s’arrêter, nous la déployons en cluster avec Galera : chaque nœud accepte les écritures et les réplique aux autres de façon synchrone. Un serveur peut tomber sans qu’une transaction validée soit perdue. Haute disponibilité

PostgreSQL

Proposée au même titre que MariaDB sur nos hébergements, au choix. Ses points forts pour une application métier : des contraintes d’intégrité riches, des transactions solides et des types de données avancés — JSON, tableaux, recherche plein texte.

Nous écrivons nos applications de sorte que passer de MariaDB à PostgreSQL ne touche que la couche d’accès aux données, pas le code métier. Applications métier

MongoDB

Base orientée documents, adaptée aux données dont la structure varie d’un enregistrement à l’autre, ou qui évolue souvent. Nous l’exploitons en replica set : plusieurs copies synchronisées, et la bascule automatique vers une autre copie si le serveur principal tombe.

Nous la déployons notamment pour les sites à fort trafic, en complément de la base relationnelle, quand une partie des données s’y prête mieux. Sites à fort trafic

Elasticsearch

Moteur de recherche et d’indexation. Il prend le relais de la base de données quand la recherche devient lourde : recherche plein texte tolérante aux fautes, filtres combinés sur un catalogue, suggestions à la frappe, analyse de journaux.

Sur une boutique au catalogue important, c’est souvent ce qui garde la recherche instantanée quand le trafic monte. Nous déployons Elasticsearch ou OpenSearch, son équivalent libre, selon le projet, et en cluster répliqué quand la disponibilité l’exige.

Valkey

Base de données en mémoire, compatible avec Redis. Nous nous en servons comme cache d’objets — le résultat d’une requête coûteuse, gardé quelques minutes plutôt que recalculé à chaque visite —, pour les sessions des utilisateurs et comme file de tâches légère. Tout tient en mémoire, d’où des réponses en une fraction de milliseconde.

Valkey est né en 2024 d’un fork de Redis, quand celui-ci a quitté la licence BSD. Porté par la Linux Foundation, il garde cette licence et reste développé en commun, sans dépendre d’un éditeur unique. Il parle le même protocole et accepte les mêmes commandes : une application écrite pour Redis s’y connecte sans modification. Optimisation de site · Sites à fort trafic

Serveurs web et caches

LiteSpeed

Le serveur web de nos hébergements mutualisés. Nous l’avons préféré à Apache pour sa meilleure gestion des processus PHP, son support de HTTP/2 et son cache intégré : la mise en cache est faite par le serveur, pas par PHP.

Le plugin de cache LiteSpeed est fourni gratuitement avec l’hébergement pour WordPress, et le module correspondant accélère PrestaShop et Magento sans surcoût — aucune extension de cache payante à acheter. LiteSpeed lit par ailleurs la configuration écrite pour Apache, fichiers .htaccess compris : un site conçu pour Apache fonctionne sans modification. Hébergement web Linux

Apache

Le serveur web historique, et encore l’un des plus répandus. Sa force est sa souplesse : chaque dossier peut porter ses propres règles dans un fichier .htaccess, sans toucher à la configuration du serveur, et ses modules couvrent à peu près tous les besoins.

Nous l’exploitons là où il est en place, notamment sur les serveurs cPanel que nous infogérons, où le serveur web et les versions de PHP se recompilent avec EasyApache. Infogérance cPanel

Nginx

Serveur web et proxy inverse conçu pour tenir un très grand nombre de connexions simultanées avec peu de mémoire. Nous le plaçons surtout devant les applications — Node.js, Spring Boot : il porte le certificat, compresse les réponses, sert les fichiers statiques et permet de basculer d’une version de l’application à la suivante sans coupure.

Il sert aussi de répartiteur de charge, au même titre que HAProxy ou Traefik, selon le contexte. Haute disponibilité

Caddy

Serveur web écrit en Go, dont la particularité est le HTTPS automatique : il obtient les certificats et les renouvelle seul, sans outil à ajouter ni tâche planifiée à surveiller. Il prend aussi en charge HTTP/3 d’origine.

Sa configuration tient souvent en quelques lignes lisibles, ce qui en fait un bon choix pour exposer une application ou un service dont la configuration doit rester simple à relire et à reprendre.

Varnish

Cache HTTP placé devant le serveur web. Une page déjà calculée est servie directement depuis la mémoire, sans solliciter PHP ni la base de données : sous une forte affluence, c’est souvent ce qui fait la différence entre un site qui tient et un site qui tombe.

Nous le mettons en place quand le volume le justifie, notamment sur les sites à fort trafic, où il s’ajoute au cache LiteSpeed. Sites à fort trafic

Conteneurs et exploitation

Docker

Une application livrée en image Docker emporte son environnement avec elle : elle tourne en production comme sur le poste de développement. Une bonne partie des incidents de mise en production disparaît avec ce seul changement.

Nous exploitons Docker en mode Swarm, l’orchestrateur intégré : il répartit les conteneurs sur plusieurs machines, les redémarre ailleurs si un nœud tombe et met à jour sans coupure. Il fait moins de choses qu’un orchestrateur plus lourd, et c’est son intérêt pour la majorité des projets — moins de pièces mobiles, et moins de choses à comprendre le jour où quelque chose casse.

Un conteneur est jetable, vos données ne le sont pas. Nous sortons donc l’état des conteneurs — bases répliquées, stockage partagé, caches en mémoire —, pour qu’un conteneur puisse être détruit et recréé sans que personne ne s’en aperçoive. Vous gardez votre chaîne de construction des images ; nous prenons la production. Hébergement Docker · Consulting DevOps

GitLab

Forge logicielle libre qui réunit au même endroit ce qu’un projet dispersait souvent entre plusieurs services : les dépôts Git, les demandes de fusion et leur relecture, le suivi des tickets, l’intégration continue et le registre d’images Docker.

Son intégration continue est décrite dans un fichier versionné avec le code : chaque modification déclenche les mêmes vérifications, dans le même ordre, sans qu’une personne ait à s’en souvenir. Ce site en est un exemple. Son code est hébergé sur une instance GitLab auto-hébergée, et chaque envoi lance la vérification des types, les tests, la construction du site et de son image Docker, puis un audit Lighthouse de l’image construite.

Une instance à soi garde le code, les tickets et les secrets de déploiement hors des plateformes en ligne, et son coût ne dépend ni du nombre d’utilisateurs ni des minutes de build. Nous en hébergeons et en exploitons pour nos clients. Hébergement GitLab

Ansible

Outil d’automatisation de la configuration des serveurs. Plutôt que d’installer et de régler une machine à la main, on décrit dans des fichiers l’état qu’elle doit atteindre — paquets, fichiers de configuration, services, utilisateurs — et Ansible l’y amène. Ces fichiers se versionnent comme du code : chaque changement est tracé, relu et reproductible.

Il ne demande aucun agent sur les machines : une connexion SSH suffit. Et ses opérations sont idempotentes : relancer une configuration déjà appliquée ne change rien, ce qui permet de la rejouer sans crainte pour corriger une dérive.

C’est par là que nous commençons une mission DevOps : tant qu’on ne sait pas reconstruire une machine à l’identique, tout le reste est du bricolage. Selon le contexte, nous employons aussi SaltStack, et Rundeck ou Jenkins pour enchaîner les opérations. Consulting DevOps