Un logiciel sur mesure, conçu par ceux qui le feront tourner.
Outils internes, portails clients, produits SaaS et API. Une seule équipe senior conçoit, développe, livre et maintient le système, sans rupture entre « l'agence » et « la maintenance ».
La plupart des logiciels sur mesure échouent après leur lancement, pas avant. Ils sont construits par une équipe, transmis à une autre, et plus personne ne se souvient pourquoi le worker de la file d'attente redémarre chaque nuit. Nous évitons cela en gardant les mêmes ingénieurs sur l'architecture, le code et l'exploitation, afin que les décisions prises en semaine un aient encore du sens en année deux.
Notre stack par défaut est TypeScript de bout en bout : API Node.js, front-ends React ou Next.js, PostgreSQL, déployés sous forme de conteneurs sur AWS avec une infrastructure définie en code. Quand un projet se prête mieux à Laravel, nous utilisons Laravel. Dans les deux cas, vous obtenez des contrats typés, des tests automatisés et un pipeline CI/CD dès la première semaine.
Full-stack, pas juste « front et back ».
Découverte produit et technique
Une courte phase de découverte payante transforme un brief flou en un backlog cadré, un modèle de données et une première architecture. Vous pouvez l'emporter où vous voulez, y compris ailleurs.
API back-end et données
API Node.js (NestJS, Fastify) ou Laravel, schémas PostgreSQL pensés pour les cinq prochaines années, files d'attente, tâches en arrière-plan, webhooks et intégrations tierces.
Des interfaces que les gens utilisent vraiment
Applications React et Next.js avec rendu côté serveur là où cela compte, des composants accessibles, et un design system qui survit à l'arrivée du deuxième designer.
Authentification et permissions
SSO, OAuth, rôles et isolation des tenants, faits une bonne fois pour toutes, pour qu'ils ne deviennent jamais ce qui bloque un nouveau client.
Tests et CI/CD
Tests unitaires, d'intégration et end-to-end exécutés à chaque pull request, environnements de prévisualisation pour la revue, et un déploiement qui n'a rien d'excitant.
Déploiement et exploitation
Conteneurs sur AWS (ECS, App Runner), infrastructure en code avec CDK, supervision, alertes et un runbook que votre équipe peut suivre à 3 h du matin.
Ce que vous obtenez
- Une application fonctionnelle dans vos propres dépôts et comptes cloud, dès le premier jour
- Des notes d'architecture et un modèle de données que votre prochain ingénieur pourra comprendre
- Une suite de tests automatisés et un pipeline CI/CD avec environnements de prévisualisation
- Une infrastructure définie en code, avec dev, staging et production séparés
- Une démo hebdomadaire, un rapport d'heures chaque semaine, et un backlog que vous pouvez reprioriser à tout moment
C'est fait pour vous si
- Vous avez besoin d'un outil interne, d'un portail ou d'un produit SaaS et voulez qu'il soit bien construit dès la première fois
- Votre prestataire actuel livre des fonctionnalités, mais personne ne peut expliquer comment le système fonctionne
- Vous avez une idée de produit et avez besoin d'une équipe senior pour la faire passer du cahier des charges à des utilisateurs payants
Comment se déroule une mission
Vous obtenez un ingenieur senior qui livre comme une petite equipe — avec un taux horaire transparent, un reporting hebdomadaire et sans frais d'agence. Ajustez les heures a la hausse ou a la baisse selon les besoins du projet.
- 01Découverte — une à deux semaines pour définir le périmètre, le modèle de données, l'architecture et un premier jalon réaliste.
- 02Fondations — dépôts, environnements, CI/CD, authentification et modèle de domaine central ; un squelette déployable dès les premières semaines.
- 03Itérations — des incréments hebdomadaires, chacun démontré sur un environnement de prévisualisation et livré en production quand vous le décidez.
- 04Transmission ou exploitation — nous documentons, formons votre équipe, puis soit transmettons le système, soit restons pour l'exploiter et le faire évoluer.
Les questions qu'on nous pose avant chaque mission
TypeScript ou Laravel, lequel allez-vous utiliser ?
Notre choix par défaut est TypeScript de bout en bout (Node.js, React/Next.js, PostgreSQL), car un seul langage sur toute la stack permet à une petite équipe d'aller vite. Nous utilisons Laravel quand le projet est riche en contenu, quand votre équipe connaît déjà PHP, ou quand les briques intégrées de Laravel (authentification, files d'attente, outils d'administration) raccourcissent le chemin. Nous vous dirons lequel, et pourquoi, avant d'écrire la moindre ligne de code.
À quelle vitesse pouvons-nous avoir quelque chose en production ?
Un squelette déployable avec authentification, CI/CD et environnements existe généralement dans les deux à trois premières semaines. La première vraie fonctionnalité entre les mains des utilisateurs suit habituellement le même mois. Les outils modernes assistés par IA accélèrent les tâches répétitives ; la revue par des seniors garantit la qualité.
Qui est propriétaire du code ?
Vous, dès le premier commit. Tout se trouve dans votre organisation GitHub et vos comptes AWS. Il n'y a ni verrouillage propriétaire ni frais de licence.
Pouvez-vous travailler avec nos développeurs actuels ?
Oui, et c'est souvent la meilleure configuration. Nous prenons en charge l'architecture et les parties difficiles, travaillons en binôme avec votre équipe sur le reste, et la laissons capable de tout maintenir sans nous.
Combien ça coûte ?
Facturation horaire, en time-and-materials, facturée chaque mois par une société de l'UE. Pas de mise en scène au forfait : vous obtenez une estimation réaliste par jalon, un rapport d'heures hebdomadaire, et la liberté d'augmenter ou d'arrêter à tout moment.
Notre point de vue
Comment nous construisons des applications web : les trois premières semaines, et l'année qui suit
Cette année, nous avons livré deux plateformes web très différentes avec la même méthode. La première est une plateforme...
septembre 2026
Un monorepo avec trois applications : comment nous ne construisons que ce qui a changé, et avons fait passer le pipeline de huit minutes à trois
Trois applications Next.js, quatre paquets partagés, un seul dépôt. C'est la forme de la plateforme que nous exploitons...
septembre 2026
DynamoDB single-table ou Postgres ? Comment nous avons choisi, par workload, et où nous nous sommes trompés
Le débat DynamoDB contre Postgres se mène généralement comme une religion. Un camp dit que les données relationnelles ap...
septembre 2026Un produit à construire ?
Missions flexibles horaires / time-and-materials, 100% remote, B2B. Communication directe avec l'ingenieur qui fait le travail — sans intermediaires, sans discours commercial.