Une application métier en production, prix et délai fixés avant de commencer.
Une semaine pour un irritant précis, quatre semaines pour un outil complet, trois semaines pour reprendre l'existant. Le périmètre s'écrit avant de commencer.
Tout le monde écrit la même chose.
« Expertise », « sur mesure », « équipe dédiée », « partenaire de confiance ». Ces mots ne coûtent rien à écrire et n'engagent personne. Voici ce que nous mettons dans le contrat à la place.
Ce qui tient en quatre semaines a changé.
Le goulot d'étranglement d'un projet logiciel n'a jamais été la frappe au clavier. C'est décider, relire, intégrer, et prouver que ça tient en production.
Nous avons industrialisé la partie production. Nous n'avons compressé ni la relecture, ni les tests, ni la sécurité, ni la migration dans votre système d'information. C'est précisément là que passent les quatre semaines — et c'est là que les projets meurent quand on ne le fait pas.
La limite n'est plus notre capacité de production. C'est la vitesse à laquelle vous pouvez décider. D'où la semaine 1.
Le jour 28, c'est en production. Le jour 29, vos équipes travaillent dedans.
Un outil, pas un pilote
Un utilisateur métier ouvre l'application et fait son travail dedans. Pas une démonstration, pas une preuve de concept à industrialiser plus tard.
Chez vous, pas chez nous
Les données restent dans votre système d'information, chez votre hébergeur, sous vos comptes. Nous n'hébergeons rien qui vous appartienne.
Un interlocuteur et un runbook
Si quelque chose casse, il y a un interlocuteur joignable et un runbook d'exploitation livré au jour 28 : redémarrage, rollback, restauration de sauvegarde. Pas un formulaire de support.
Les quatre semaines
Chaque semaine a une sortie vérifiable. Si une sortie n'est pas atteinte à sa date, nous vous le notifions par écrit à la fin de la semaine concernée. La notification porte la cause et l'effet sur la date du jour 28. Ces quatre sorties sont des points de contrôle, pas quatre garanties. La garantie porte sur la mise en production au jour 28 sur le périmètre signé, jamais sur une sortie intermédiaire.
- Ateliers avec vos utilisateurs, pas avec vos acheteurs
- Ce qui n'entre pas dans le périmètre est écrit noir sur blanc
- Architecture cible et choix d'hébergement
- Infrastructure décrite en Terraform dès le premier jour
- Pipeline CI/CD et authentification sur votre annuaire
- Premiers écrans navigables
- Règles de gestion, cas limites, imports de données
- Vos utilisateurs testent en continu, pas à la fin
- Observabilité et alertes câblées
- Bascule et reprise de données
- Runbook d'exploitation et procédure de rollback
- Handover à l'équipe qui reprend
Ce que vous emportez le jour 28
Rien n'est en option, rien n'est facturé en supplément, et rien ne dépend de nous pour continuer à fonctionner.
C'est le test que nous vous invitons à faire passer à n'importe quel prestataire : demandez la liste, par écrit, avant de signer.
Ce que « 28 jours » veut dire concrètement : un CRM interne, en production.
Un cas réaliste, au palier intermédiaire du forfait. Une équipe commerciale de quarante personnes travaille sur un tableur partagé et un outil générique que personne n'a configuré. Elle a besoin de son propre CRM, connecté à son système d'information, avec ses règles d'accès.
Périmètre en green field — littéralement « terrain vierge » : on part d'un dépôt vide, sans code hérité ni base existante à reprendre. C'est la condition de la date : aucune découverte tardive dans un système que nous n'avons pas écrit.
Notre propre CRM tourne en production — c'est l'outil qui gère nos contacts et nos relances. Voir le produit.
- Contacts : fiche, historique, rattachement, doublons signalés
- Sociétés : hiérarchie mère-filles, portefeuille par commercial
- Recherche et filtres sauvegardés, import initial depuis vos fichiers
- Pipeline par étapes, avec les règles de passage de votre métier
- Montants, échéances, probabilité, motifs de perte
- Historique des changements : qui a modifié quoi, et quand
- Rôles et hiérarchie : un commercial, un manager, une direction
- Jeux de permissions cumulables, indépendants des rôles
- Cloisonnement par portefeuille, testé et documenté
- Vos assistants internes interrogent le CRM sans export ni copie
- Portée limitée par les mêmes droits que l'interface, jamais au-delà
- Journal des accès : chaque requête est traçable
- Pipeline, taux de conversion, activité par commercial
- Vues manager et direction, chiffres calculés à la source
- Export des données pour votre outil décisionnel
Dix artefacts, livrés avec l'application, pas après. Le dixième est la spécification OpenAPI : elle suppose que l'application expose une API, ce que le cadrage tranche. Sans API à exposer, il y en a neuf, et le SOW le dit avant que vous signiez. Le dossier d'architecture suit vos propres normes et vos schémas d'intégration : ce n'est pas notre modèle de document, c'est le vôtre.
La même liste vaut pour n'importe quel projet du forfait. Ici, elle est simplement instanciée sur un CRM.
Aucune reprise de l'historique d'un CRM existant, aucune synchronisation bidirectionnelle avec un ERP, aucun moteur de calcul de commissions. Ces trois-là changent de forfait, et nous le disons au cadrage — pas au jour 21.
À l'inverse, si nous prenons de l'avance : au cadrage nous écrivons le périmètre contractuel et la suite de votre liste de priorités. Le temps gagné y passe, dans l'ordre que vous avez fixé. Sur ce cas, ce serait le calcul de commissions, puis les objectifs par commercial. Trois bornes. Nous jugeons seuls s'il y a de l'avance et ce qui tient dedans. Ce qui est pris reste dans les volumes du palier signé. Ce qui est pris n'entre pas dans le périmètre signé, et la garantie ne le couvre donc pas. L'avance ne se reporte pas après le jour 28 et ne se convertit ni en avoir ni en remise.
Et ce que la date exige de vous : les accès au cloud et à l'annuaire ouverts au jour 1, vos guidelines d'architecture transmises au cadrage, un référent métier joignable dans la journée. Ces trois points sont au contrat au même titre que les nôtres — c'est le seul endroit où le délai peut se perdre.
Ce que quatre semaines ne permettent pas
Un forfait fermé n'a de valeur que s'il est fermé des deux côtés. Voici ce que nous refusons d'y mettre, parce que nous ne saurions pas le tenir.
Les deux dernières limites ne portent pas sur la technique. Ce n'est plus là que le temps se perd.
Si votre projet figure dans cette liste, dites-le au premier rendez-vous. Nous vous dirons non en 20 minutes plutôt qu'en trois mois.
Les prix sont écrits ici, pas dans un formulaire.
Chaque ligne a une durée, un prix de départ et le détail de ce qui le fait monter. Vous pouvez calculer votre budget avant de nous parler — c'est le but.
Si vous hésitez : commencez par la reprise. C'est la seule ligne où vous n'avez rien à croire sur parole — vous jugez le résultat sur des artefacts vérifiables, sur une application que vous connaissez déjà.
Un irritant précis : un export fait à la main chaque lundi, une double saisie entre deux logiciels, un tableur que douze personnes s'échangent. Cinq jours, et il est en production.
Deux livrables sortent de ces cinq jours, pas un seul : l'outil, et le périmètre écrit et chiffré du forfait suivant — paliers, obligations réciproques, signable tel quel. C'est le cadrage payant du forfait qui vient après, pas une offre à part : votre spécification n'est pas un devis gratuit, c'est un livrable payé.
Une application qui tourne, que plus personne ne maintient, dont personne ne sait comment elle se redéploie. Trois semaines pour la remettre sous contrôle — et rien à croire sur parole : le résultat est vérifiable ligne par ligne.
- L'application sous votre contrôle (accès, secrets et pipeline de déploiement repris ou remis en état de marche). Nous rejouons le déploiement de bout en bout devant votre équipe
- Un dossier de reprise écrit (architecture telle qu'elle est, dépendances, procédure de déploiement, de rollback et de restauration)
- Le rapport d'audit des jours 1 et 2, remis dans tous les cas : la dette y est chiffrée en jours de remise en état et classée par priorité
- Des tests de non-régression sur cinq parcours critiques au maximum, que vous désignez au jour 1. La référence est ce que l'application fait aujourd'hui, relevé par nous au début de la reprise
- L'état des sauvegardes, établi par une restauration réellement tentée. Si aucune sauvegarde n'existe, le dossier de reprise le dit ; en mettre une en place sort du périmètre iso-fonctionnel
- Une session de handover avec votre équipe
- Le code est à vous : cession pleine à paiement, licence d'exploitation dès la livraison
- Aucune évolution fonctionnelle pendant ces trois semaines
Les deux premiers jours ouvrés de la mission sont un audit d'éligibilité. Nous lisons le code et les dépendances, puis nous mesurons la dette. Nous jugeons alors la capacité de l'application à être reprise au prix et dans le délai signés. Vous faites examiner votre application avant que l'un de nous s'engage sur les trois semaines.
Au plus tard à l'issue du deuxième jour ouvré, nous vous notifions par écrit l'une des deux suites : la confirmation du forfait, qui se poursuit alors sans changement, ou notre sortie de la mission.
Cette sortie est unilatérale : nous seuls pouvons la prononcer. En cas de sortie, nous remettons le rapport d'audit écrit et vous nous devez 3 000 € HT au titre de cet audit livré. Le reste du forfait n'est pas dû. L'acompte déjà versé s'impute sur ce montant ; l'excédent vous est remboursé dans les 30 jours.
- Le palier est arrêté au cadrage et écrit au contrat — il ne bouge plus ensuite
- Suite de tests à 80 %, revue de sécurité, mise en production
- Terraform, dossier d'architecture, runbook, handover
- Livré après le jour 28 sur le périmètre signé : le solde n'est pas dû
- Le code est à vous : cession pleine à paiement, licence d'exploitation dès la livraison
- Du temps d'avance ? Nous prenons la suite de votre liste de priorités, sans surcoût, dans les volumes du palier signé et hors du périmètre garanti
- Tout ce qui figure dans la liste des exclusions
Liste fermée : supervision et alertes, sauvegardes et test de restauration trimestriel, patchs de sécurité des dépendances, certificats, rapport mensuel. Rien d'autre n'est couvert par l'abonnement — ce n'est ni un support illimité, ni une astreinte.
Incident applicatif, donnée corrompue, régression : forfait de 600 € HT par incident standard — diagnostic, correctif, post-mortem d'une page. Le diagnostic est toujours inclus ; au-delà de deux jours estimés, rien n'est engagé avant votre accord sur devis.
Enveloppe mensuelle d'évolutions. Les demandes acceptées au backlog sont réalisées dans la limite d'une charge estimée de deux jours ; chaque évolution a un périmètre écrit accepté avant réalisation. L'enveloppe n'est pas reportable d'un mois sur l'autre.
- Hébergement sur votre compte cloud, facturé par votre fournisseur : nous ne prenons pas de marge dessus
- Réversibilité : l'infrastructure en Terraform est dans votre dépôt, livrée au jour 28
Plusieurs métiers, plusieurs sites, une refonte de fond : au-delà du palier maximal du forfait fermé, un prix affiché serait un chiffre en l'air. Nous découpons en blocs de quatre semaines, chacun avec son prix ferme et sa mise en production, et vous décidez de continuer bloc par bloc.
Un dépassement marginal du palier maximal ne bascule pas mécaniquement au bloc supérieur : le bloc est ajusté au périmètre réel.
Le code est à vous : cession pleine à paiement, licence d'exploitation dès la livraison — chaque bloc porte sa propre clause de cession.
Les objections qu'on nous fait
Pour un ERP complet, non. Pour la première version utilisable par vos équipes, si. Nous cadrons le périmètre avant de signer, pas après.
Ce que vous demandez en cours de route est chiffré à part, avant d'être fait — le forfait ne se dilue pas, c'est ce qui garantit la date. Ce que nous ajoutons de notre propre initiative, parce que nous avons de l'avance, ne coûte rien : c'est la liste de priorités écrite au cadrage, prise dans l'ordre. Ce qui est pris reste dans les volumes du palier signé. Ce qui est pris n'entre pas dans le périmètre signé, et la garantie ne le couvre donc pas.
C'est le défaut du modèle, et voici comment nous le neutralisons : le périmètre contractuel est un plancher, pas un plafond. La liste de priorités arrêtée au cadrage nous dit quoi faire du temps d'avance, sans négociation à mi-parcours. Vous ne pouvez pas y perdre : le pire des cas est ce qui est écrit au contrat, livré au jour 28.
N'importe quelle équipe capable de lire du Terraform et un dossier d'architecture. C'est précisément pour cela que nous les livrons, et que le handover est enregistré.
Dans la relecture, les tests, la revue de sécurité et la mise en production. Le temps que nous ne passons plus à produire, nous le passons à vérifier — c'est ce qui fait la différence entre du code qui existe et une application dont vos équipes dépendent le lundi matin.
C'est le résultat le plus documenté du secteur, et il est logique : produire plus vite ne sert à rien si la relecture, la recette, la sécurité et la mise en production restent au même rythme. Le gain se mesure en bout de chaîne, pas au clavier. C'est cette chaîne-là que nous vendons.
Il n'y en a pas de caché : le périmètre est plus petit, et il est écrit. Nous vendons une première version en production, pas trois ans de régie.
Vingt minutes suffisent pour savoir si votre projet tient en quatre semaines.
Venez avec le problème métier, pas avec un cahier des charges. Vous repartez avec un périmètre chiffré, ou avec un non argumenté.