Technologies

Ce sur quoi nous développons, et pourquoi

Une liste de stack est facile à établir. L’important, c’est la justification, car c’est vous qui devrez conserver le code et embaucher quelqu’un pour le maintenir.

Pile technique

Choisie pour que vous puissiez recruter dessus

Nous choisissons délibérément des technologies grand public et bien supportées. Le critère n’est pas ce qui est intéressant à développer, mais si vous pourrez recruter quelqu’un pour en assurer la maintenance dans trois ans.

Développement mobile

Natif

Swift
Objective-C
Kotlin

Multiplateforme

Flutter
React Native
Xamarin

Développement web

Front-end

React
Angular
Vue
TypeScript
JavaScript

Back-end

Node.js
Python
Java
PHP

Données & Stockage

Bases de données

PostgreSQL
MySQL
MongoDB

Nous travaillons également avec

Frameworks

Next.js
Nest.js
Laravel
Django
FastAPI
Svelte
Astro
Tailwind CSS

IA & données

Mistral
Claude
OpenAI
Llama
LangChain
pgvector
Qdrant
Pandas

Cloud & DevOps

AWS
Azure
Google Cloud
Docker
Kubernetes
Terraform
GitHub Actions
Cloudflare
Redis
LiteSpeed

Plateformes & API

WordPress
Shopify
WooCommerce
GraphQL
REST
Stripe
Firebase
Supabase
Prisma

Les raisons

Front-end

Next.js avec React et TypeScript

Le rendu côté serveur est activé par défaut, ce qui compte plus qu'avant : les robots d'IA comme GPTBot, ClaudeBot et PerplexityBot n'exécutent généralement pas JavaScript, donc une application rendue côté client est presque invisible pour eux. TypeScript parce qu'une erreur de type détectée à la compilation est gratuite, alors que la même erreur trouvée en production ne l'est pas.

Back-end

Node.js, Laravel ou Python — choisi projet par projet

Node lorsque le front-end est déjà en TypeScript et que le partage de types est économiquement justifié. Laravel lorsque l'équipe qui maintient le projet est une équipe PHP, ce qui est souvent le cas dans les PME britanniques. Python lorsque le travail est axé sur les données ou les modèles. Nous choisissons en fonction de qui maintient le projet, pas de nos préférences.

Base de données

PostgreSQL, ou MySQL lorsque l'hébergeur l'impose

Postgres pour tout projet avec des structures de données complexes, des colonnes JSON ou une recherche vectorielle via pgvector. MySQL lorsque l'infrastructure existante ou l'hébergement mutualisé l'exige — ce qui est courant et parfaitement viable.

Mobile

Flutter ou React Native, natif lorsque justifié

Le multiplateforme permet d'économiser environ 30 à 40 % et convient à la plupart des applications professionnelles. Natif en Swift ou Kotlin lorsque l'application repose fortement sur les fonctionnalités de l'appareil — travail continu avec la caméra, géolocalisation en arrière-plan, animations complexes continues.

Mistral, Claude et modèles open-weight

Évalués par rapport à votre propre jeu de tests plutôt qu'à un classement éditorial. L'auto-hébergement d'un modèle ouvert devient rentable à volume élevé et constant ou lorsque les données ne peuvent pas quitter votre infrastructure — c'est un calcul, pas une préférence.

Infrastructure

Docker, AWS ou votre hébergeur actuel

Conteneurisé pour garantir un fonctionnement identique en local et en production. Nous déployons sur ce que vous utilisez déjà plutôt que de vous faire migrer vers une solution qui nous conviendrait mieux.

Questions sur la stack

Une seule question décide de la plupart des choix : qui assurera la maintenance dans trois ans, et pourrez-vous recruter ces profils ? Une stack élégante mais pour laquelle il est impossible de recruter est un passif que vous héritez. Nous prenons aussi en compte ce que vous utilisez déjà — introduire un second langage dans une petite équipe a un coût réel.

Oui, et généralement nous devrions le faire. Réécrire un système fonctionnel dans nos outils préférés n'est presque jamais dans votre intérêt. Nous adoptons vos conventions, votre modèle de branches et votre processus de revue. Lorsque nous estimons qu'un choix technologique vous freine, nous le démontrons avec des chiffres plutôt qu'avec des préférences.

Quand c’est pertinent, oui — et c’est plus fréquent que les développeurs ne veulent bien l’admettre. Si votre équipe publie souvent et a besoin d’un contrôle éditorial total sans intervention d’un développeur, une installation WordPress sécurisée est la réponse pragmatique. Ce que nous ne ferons pas, en revanche, c’est empiler deux constructeurs de pages et vingt extensions dessus en prétendant qu’il s’agit d’un site web.

Parce que c’est vous qui gardez le code, pas nous. Une technologie fiable, bien supportée et disposant d’un large vivier de recrutement est un atout du livrable, pas un manque d’ambition. Nous utiliserons quelque chose de plus récent uniquement si cela résout un vrai problème, et nous vous expliquerons clairement les compromis à faire.