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, vous le savez le vendredi, pas au 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.
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 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.
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. La validation par les magasins d'applications ne dépend pas de nous : elle sort du délai de vingt-huit jours.
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 de mettre dedans, parce que nous ne saurions pas le tenir.
Vous remarquerez que 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 trente 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.
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.
Deux jours d'évolutions par mois, pris quand vous en avez besoin. Chaque évolution a un périmètre écrit, accepté avant réalisation. Non consommés, ils ne sont pas reportés — et vous pouvez retirer la ligne 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.
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é.
