Plans de travail
Nos méthodes de travail.
Trois planches d'un même jeu. La forme d'un projet, la forme des systèmes que nous construisons, et la forme d'une fonctionnalité IA. Chaque chiffre porté dessus est un chiffre que ce studio publie déjà.
Du brief à la mise en ligne, dessiné à l'échelle.
Le cadrage se compte en jours. La construction se compte en semaines. Le dessin maintient les deux échelles séparées pour qu'aucune ne flatte l'autre.
Trois questions, avant toute signature. Combien de temps avant qu'une personne réponde, combien de temps avant d'avoir un vrai document, combien de temps avant que quelque chose tourne.
- Une personne répond : un jour ouvré.
- Un périmètre écrit arrive : environ trois jours ouvrés.
- Un projet à périmètre fixe dure de deux à huit semaines.
Dessiné, pas aligné en promesses. Portées sur un axe de temps plutôt qu'alignées en quatre promesses, la différence d'ordre de grandeur saute aux yeux.
Seule l'étape de construction est ouverte. Et encore : elle a un plancher et un plafond. Elle avance par démonstrations hebdomadaires dans un environnement réel, donc le client peut réorienter le travail à chaque point de contrôle.
Les ajustements font partie du contrat. Tout changement qui élargit le périmètre est re-chiffré par écrit avant d'être construit.
La garantie court au-delà de l'axe. La garantie de correction de trente jours continue après la fin du dessin, d'où sa propre rupture d'échelle.
Les cinq étapes
- 01
Prise de contact
≤ 1 jour ouvré
Vous envoyez un brief. Nous répondons sous un jour ouvré : si le projet nous correspond, qui le pilotera, et ce qu'il nous manque encore pour le cadrer.
Pas de présentation commerciale, pas de phase de découverte qui se transforme en année de découverte.
- 02
Cadrage
~3 jours ouvrés
Nous concevons l'architecture du travail et envoyons un périmètre écrit avec un prix fixe, en général sous trois jours ouvrés environ. Ce document vous appartient, que vous donniez suite ou non.
Quand le problème n'est pas encore assez clair pour être chiffré, le même travail devient un sprint de cadrage d'une semaine dont les honoraires sont déduits de la construction.
- 03
Développement
2–8 semaines
Démonstrations hebdomadaires dans un environnement réel, jamais de boîte noire.
Une application se livre en trois à sept semaines, une application mobile en quatre à sept, un produit IA complet en cinq à huit. Une page d'atterrissage ou un petit site vitrine, dix à vingt jours ; un audit ou un lot restreint, cinq à quinze.
- 04
Mise en ligne
Lancement
Nous prenons en charge le déploiement, le DNS, la supervision et la soumission aux magasins d'applications. Vous recevez un document de passation, vous pouvez modifier le contenu qui vous appartient, et la propriété intellectuelle vous est transférée au paiement final.
Le site ne publie aucune durée pour la semaine de lancement : le dessin en fait donc un jalon plutôt que d'en inventer une.
- 05
Garantie
30 jours
Trente jours de correction de bogues sur chaque projet : si cela casse en production, nous réparons.
Ensuite, une maintenance mensuelle facultative pour continuer à livrer : nouvelles fonctionnalités, infrastructure, travaux d'IA. Une place par trimestre, pour que chaque projet garde un ingénieur senior.
La même colonne sous la plupart de nos livraisons.
Pas une architecture de référence recopiée d'un schéma d'éditeur. Chaque nom porté sur la planche figure dans la pile technique d'un projet que nous avons réellement livré.
Deux surfaces client. Toutes deux écrites dans le même TypeScript.
- Web : une application Next.js App Router, bilingue sur de vraies routes grâce à next-intl (Dira Education, ES QS, Baki, AEVORA et ce site).
- Mobile : une application Expo et React Native (EasyKingsPay, publiée sur l'App Store et sur Google Play).
Derrière elles, une frontière typée. Validée par schéma, puis soit un service Express autonome quand le produit a une vie propre (Dira Education, PulseLab, Simplified Invoice), soit des route handlers Next.js quand ce n'est pas le cas.
Un seul schéma en dessous. Prisma au-dessus de PostgreSQL, avec MySQL quand l'hébergeur du client l'impose, comme sur AEVORA.
La lisière n'est jamais générique. Ce qui pend sur le côté de la planche est ce qui fait qu'une construction cesse d'être un gabarit.
- Paiement mobile à l'encaissement : Tyketz, Simplified Invoice.
- Nodemailer en SMTP derrière les formulaires de contact : SN Commercial, SN Finishing.
- Puppeteer pour les PDF de relevés et de factures : Simplified Invoice.
- Socket.IO pour la capture en direct : PulseLab.
- Stockage objet pour les téléversements.
Les trois bandes
- 01
Surfaces client
Next.js · React · TypeScript · Expo
Next.js App Router avec React, TypeScript et Tailwind sur le web ; Expo et React Native sur mobile, avec les builds EAS et les mises à jour à distance.
Bilingue EN/FR sur de vraies routes localisées via next-intl, et non un simple échange de chaînes côté client. C'est aussi ce qui rend la version française indexable.
- 02
Frontière typée et services
Express · route handlers · zod
Tout ce qui passe d'un client vers un service est analysé contre un schéma avant que quoi que ce soit en aval ne le voie.
L'authentification, les rôles, les permissions et les limites de débit vivent sur cette lisière : c'est pourquoi elle est le seul élément mis en couleur sur le dessin.
Un produit qui a sa vie propre reçoit un service Express autonome ; sinon, ce sont des route handlers Next.js et un seul déploiement.
- 03
Données
Prisma · PostgreSQL
Un seul schéma Prisma, migré plutôt que retouché à la main, au-dessus de PostgreSQL, ou MySQL quand l'hébergeur du client l'impose.
Le schéma est le document à partir duquel tout le reste de la construction se discute : c'est pourquoi la modélisation des données a lieu au cadrage et non en semaine quatre.
Une fonctionnalité IA, c'est d'abord une frontière.
Le dessin représente l'assistant de ce site. Rien n'y est générique : chaque bloc correspond à un fichier de ce dépôt.
Un registre, une seule source de faits. La base de connaissances à partir de laquelle l'assistant répond est générée depuis le même registre de projets qui rend les études de cas, les pages sectorielles et les pages de technologies.
Ajouter un projet dans un seul fichier. Cela l'enseigne à l'assistant. Un projet marqué non listé en est filtré, et l'assistant ne le mentionnera pas de lui-même.
Rien n'est recopié à la main. Personne ne recopie un projet dans une invite, parce qu'une copie dérive dès que le registre change.
L'invite système, ce sont deux blocs. Cette base générée, plus un bloc séparé et auditable de règles de confidentialité et d'anti-injection.
Côté serveur par construction. Le module n'est importé que par une seule route d'API et par rien d'autre : il ne peut donc pas se retrouver dans un paquet livré au navigateur.
Le navigateur envoie très peu. Un message et un petit jeu d'identifiants (un sujet, un service, un identifiant de projet), et rien d'autre. Il ne peut pas envoyer de texte d'invite : c'est ce qui empêche ce point d'entrée d'être un relais de modèle gratuit.
Chaque identifiant est vérifié. Contre des ensembles fermés et contre le registre lui-même. Un identifiant que le registre ne contient pas reçoit une réponse 400 et n'atteint jamais le modèle.
La réponse revient comme une donnée. Elle est rendue par un moteur qui traite le markdown comme une donnée et ne transforme jamais en lien autre chose que https et mailto.
Les sept étapes
- 01
Registre des projets
Build · serveur
Un seul fichier rend déjà les études de cas, les pages sectorielles et les pages de technologies.
C'est aussi l'unique source de faits de l'assistant sur nos réalisations : le site et l'assistant ne peuvent donc pas se contredire.
- 02
Base de connaissances générée
Build · serveur
Construite depuis ce registre, entrées non listées filtrées. Chaque phrase remonte à un champ du registre : l'assistant ne peut répéter que des faits déjà publiés par le site.
Le coût en jetons du bloc généré est budgété dans le fichier qui le génère.
- 03
Invite système
Build · serveur
La base générée, plus un bloc séparé de règles de confidentialité et d'anti-injection, gardé comme constante propre pour que la frontière reste facile à auditer et impossible à perdre dans une retouche de contenu.
Les messages des visiteurs sont traités comme des données, jamais comme des instructions.
- 04
Requête
Navigateur
Le widget envoie la conversation et les identifiants choisis par le visiteur dans son menu : un sujet, éventuellement un service, éventuellement un projet.
Des identifiants uniquement : le navigateur n'envoie jamais de texte d'invite.
- 05
Contrôle de schéma
Serveur
La charge utile est analysée contre un schéma, le sujet et le service sont vérifiés contre des ensembles fermés, et l'identifiant de projet est vérifié contre le registre.
Un identifiant inconnu ou non listé est rejeté par un 400 et ne va pas plus loin.
La phrase de cadrage qu'un identifiant valide obtient est composée côté serveur, depuis le registre.
- 06
Appel du modèle
Serveur
Une complétion sur un modèle hébergé, avec un budget de sortie plafonné et un identifiant de modèle surchargeable par variable d'environnement, pour qu'un modèle retiré soit un changement de configuration et non une panne.
Les échecs en amont sont traduits en codes d'erreur typés plutôt qu'en trace d'exécution.
- 07
Moteur de rendu
Navigateur
La réponse est rendue par un petit moteur markdown qui traite la sortie du modèle comme une donnée : gras, listes, code en ligne et liens, jamais de HTML brut.
Chaque lien passe par une liste d'autorisation, si bien que seuls https et mailto deviennent cliquables.
Nous ne livrons pas un agent conversationnel par effet de mode. Si une fonctionnalité ordinaire résout le problème, nous le disons.
Quand l'IA est la bonne réponse, le travail se décompose en cinq pièces :
- Cadrer le problème et choisir le modèle.
- La recherche documentaire, quand la réponse dépend du contenu propre au client.
- L'appel d'outils, quand la chose doit agir.
- Un harnais d'évaluation, pour que la qualité soit mesurée et non supposée.
- Le suivi d'usage, de coût et d'abus autour de tout cela.
Les délais. Une fonctionnalité IA ciblée ajoutée à un produit existant demande cinq à quinze jours ; un produit IA complet, cinq à huit semaines.
La suite
Envoyez le brief.
Vous recevez un périmètre écrit avec un prix fixe, et ce document vous appartient que vous donniez suite ou non. Nous répondons sous un jour ouvré.
Trois ou quatre clients par trimestre