Périmètre écrit avant la signature. Prix ferme. Vos équipes s'en servent le lundi de la cinquième semaine — pas au prochain comité.
« 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.
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.
Un utilisateur métier ouvre l'application et fait son travail dedans. Pas une démonstration, pas une preuve de concept à industrialiser plus tard.
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.
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.
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.
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.
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.
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.
Nous n'avons pas de pile technique à vous vendre. Le choix est dicté par votre système d'information et par ce que vos équipes sauront reprendre après nous. Ce qui ne change jamais, quel que soit le langage : les tests, le Terraform, le dossier d'architecture et le handover.
Nous choisissons ce que vos équipes savent déjà relire et reprendre. Si votre parc est en .NET et SQL Server, nous ne vous livrons pas du Go — l'objectif est qu'après le handover, l'application vive sans nous. TypeScript et PostgreSQL sont notre défaut en l'absence de contrainte, jamais une condition.
Même principe pour l'apparence : si vous avez un design system ou une charte, l'application est livrée à votre identité, sans supplément. Nous implémentons vos composants et vos tokens plutôt que les nôtres, avec les contrastes et la navigation au clavier vérifiés.
Périmètres larges : refonte de modèle de données, gouvernance multi-org, reprise d'une instance devenue ingérable, ou intégration de Salesforce au reste de votre système d'information. La configuration d'abord, le code quand elle ne suffit plus.
Le développement Salesforce se pilote comme tout autre code : dépôt Git, tests, déploiements automatisés, revue de sécurité. Une org gouvernée par des clics et des déploiements manuels est le premier problème à traiter, avant toute nouvelle fonctionnalité.
Une application installée sur les terminaux de vos équipes terrain, connectée au même socle que le web.
Dans tous les cas, le même contrat : code dans votre dépôt, infrastructure décrite en code, dossier d'architecture, runbook, handover. Si votre besoin sort de ces trois domaines, nous vous le dirons plutôt que de l'apprendre à vos frais.
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.
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.
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.
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.
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.
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.
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é.
