Nos outils
Nous sommes volontairement étroits. Une équipe qui revendique vingt langages en apprend un sur votre projet. Ce qui ne figure pas sur cette liste, soit nous l’apprenons à nos frais, soit nous vous conseillons quelqu’un d’autre.
- TypeScript
- Python
- Go
- Kotlin
- Swift
- SQL
TypeScript des deux côtés de la plupart des produits web, pour qu’un ingénieur suive une fonctionnalité de la base de données jusqu’à l’écran. Python là où vivent les bibliothèques de données et de modèles, Go pour les services qui doivent rester petits et rapides, Swift et Kotlin pour les applications natives.
- React
- Next.js
- Vue
- Tailwind CSS
- Vite
- Playwright
React et Next.js par défaut, parce que votre équipe pourra recruter sur ces technologies après la livraison. Vue quand votre produit l’utilise déjà. Playwright pour des tests de bout en bout à chaque modification.
- Node.js
- FastAPI
- NestJS
- GraphQL
- gRPC
- REST
Node.js ou FastAPI, selon l’endroit où vit le reste du produit. REST pour la plupart des intégrations, GraphQL quand de nombreux clients lisent les mêmes données sous des formes différentes, gRPC entre services internes.
- PostgreSQL
- Redis
- ClickHouse
- Elasticsearch
- Kafka
- dbt
PostgreSQL d’abord et le plus souvent jusqu’au bout : la plupart des produits ne le dépassent jamais. Redis pour les files et le cache, ClickHouse quand l’analytique ralentirait la base principale, Kafka seulement quand les événements doivent vraiment être rejoués.
- AWS
- Google Cloud
- Docker
- Kubernetes
- Terraform
- GitHub Actions
AWS ou Google Cloud dans votre propre compte, jamais dans le nôtre : l’infrastructure est à vous dès le premier jour. Tout est décrit en Terraform et déployé depuis la CI, ce qui rend une passation propre possible.
- OpenAI
- Anthropic
- Gemini
- pgvector
- LangGraph
- PyTorch
Des modèles hébergés de plusieurs fournisseurs derrière une seule interface, pour qu’un changement de prix ou une panne soit un changement de configuration et non une réécriture. pgvector garde la recherche à côté de données que vous sauvegardez déjà.
- Swift / SwiftUI
- Kotlin / Compose
- React Native
- Expo
Swift et Kotlin natifs quand l’application dépend des fonctions de l’appareil ou des performances. React Native avec Expo quand une seule équipe doit publier sur iOS et Android et partager la logique avec le web.
- Figma
- Storybook
- Linear
- Sentry
- Grafana
- OpenTelemetry
Figma et Storybook, pour que le design et le code décrivent les mêmes composants. Sentry, Grafana et OpenTelemetry, pour qu’un problème apparaisse sur un tableau de bord avant d’apparaître dans un ticket de support.
Si votre produit tourne déjà sur autre chose, nous travaillons dans votre pile. Une réécriture est une décision justifiée par le métier, pas une préférence.
Comment nous choisissons pour un nouveau projet
Ce que votre équipe pourra maintenir après notre départ compte plus que ce qui est à la mode. Une stack pour laquelle personne chez vous ne peut recruter est une dépendance envers nous, et nous préférons ne pas vous la vendre.
Si le produit tourne déjà sur quelque chose qui fonctionne, nous le gardons. Nous ne recommandons une réécriture qu’avec une étude écrite : ce qu’elle coûte, ce qu’elle fait économiser et quand elle est rentabilisée.
Un outil que nous n’avons jamais mis en production est signalé comme un risque dans le document de cadrage, au lieu d’être appris discrètement sur votre budget.
Dites-nous ce que vous construisez
Une courte description suffit pour commencer. Nous répondons avec des questions, une fourchette et les deux ou trois éléments qui la feraient bouger.