Avant de confier un développement sur mesure, sept points se vérifient et six d'entre eux ne sont pas techniques : la propriété du code et des comptes, le modèle contractuel, l'identité réelle des personnes qui coderont, la façon dont vous verrez avancer le travail, ce qui se passe à la fin, et le coût de reprise par une autre équipe.

C'est là que les projets échouent, presque jamais sur le langage choisi.

1. À qui appartient le code, et les comptes

La question la plus importante, et celle qui se pose toujours trop tard.

Le code. Une cession de droits doit être écrite. En droit français, la propriété d'un logiciel ne se transfère pas implicitement parce que vous l'avez payé : la cession doit être expresse et délimitée. Sans clause, vous avez payé un droit d'usage, pas un actif.

Le dépôt. Il doit être hébergé sur votre organisation, avec votre facturation, et l'agence invitée dessus. L'inverse, votre code chez le prestataire, avec un export promis à la fin, est la configuration qui rend les séparations douloureuses.

Les comptes d'infrastructure. Hébergement, base de données, nom de domaine, service d'envoi d'e-mails, système de paiement : tous doivent être ouverts à votre nom, avec votre carte. Un prestataire peut y être administrateur ; il ne doit pas en être propriétaire.

Le test qui tranche : « si notre collaboration s'arrête demain matin, de quoi ai-je besoin de vous pour continuer ? » La bonne réponse est « de rien ».

2. Forfait ou régie : ce que chacun cache

Le forfait fixe un prix pour un périmètre. Il vous protège du dérapage budgétaire et transfère le risque au prestataire, qui le facture, sous forme d'une marge de sécurité. Son défaut réel n'est pas le prix : c'est qu'il rend tout changement conflictuel, parce que chaque évolution devient un avenant à négocier.

La régie facture le temps passé. Elle absorbe le changement sans friction et vous laisse le risque budgétaire. Elle exige de votre côté quelqu'un capable de prioriser chaque semaine, sans cela, elle dérive.

Notre position : forfait pour un périmètre réellement stable et bien spécifié, régie plafonnée pour tout ce qui est exploratoire. Et pour un premier projet avec une équipe que vous ne connaissez pas : un forfait court de deux à trois semaines sur un morceau réel, avant tout engagement long. C'est le seul moyen fiable d'évaluer une équipe.

3. Qui code, réellement

Le décalage le plus fréquent du marché.

Ce qu'il faut demander : les prénoms, les profils et le taux d'affectation des personnes qui travailleront sur votre projet. Pas les références de l'agence, les personnes.

Le point de vigilance : la sous-traitance en cascade. Elle n'est pas illégitime, mais elle change tout, délai de réaction, fuseau horaire, langue, et surtout la chaîne de responsabilité. Elle doit être annoncée.

Le signal qui ne trompe pas : demandez à parler à un développeur du projet, pas au commercial. Une agence qui refuse cette demande vous dit quelque chose.

4. Comment vous verrez avancer

Un environnement de recette accessible en permanence, mis à jour à chaque itération. Vous devez pouvoir cliquer dans le produit chaque semaine, pas regarder des captures d'écran en réunion.

Des itérations courtes, une à deux semaines, avec une démonstration de ce qui fonctionne, pas de ce qui est « en cours ».

Un accès en lecture au dépôt et au suivi des tâches, dès le premier jour. Même si vous ne lisez pas le code, le rythme des livraisons se voit.

Le drapeau rouge : trois semaines sans rien de cliquable. Dans un projet sain, il y a toujours quelque chose à montrer.

5. Ce qui est livré, en plus du code

À faire écrire dans le contrat, parce que cela ne va pas de soi.

La documentation d'installation et de déploiement, suffisante pour qu'une autre équipe reprenne. Le test est simple : un développeur qui découvre le projet doit pouvoir le lancer en local en moins d'une heure.

Les tests automatisés, au moins sur les parcours critiques. Un projet sans tests est un projet dont chaque modification future coûtera plus cher que prévu, c'est un transfert de coût vers vous.

Les accès et les secrets, transmis proprement, pas par message.

Le schéma de données, et la procédure de sauvegarde et de restauration. Une sauvegarde jamais restaurée n'est pas une sauvegarde.

6. Le coût de reprise

La question que personne ne pose et qui devrait décider : combien coûterait la reprise de ce projet par une autre équipe ?

Trois facteurs déterminent la réponse. Une pile technique répandue, un projet écrit dans un framework courant se reprend, un projet écrit dans une technologie de niche coûte cher à reprendre. Une architecture lisible, sans abstractions inventées pour le plaisir. Et une documentation qui existe.

Un prestataire honnête accepte cette question. Un prestataire dont le modèle repose sur votre dépendance l'esquive.

7. Ce que Cod'Hash fait, et ce que nous refusons

Nous développons sur mesure, principalement en TypeScript, React, Next.js et PostgreSQL, et nous éditons nos propres produits, CodMenu pour la restauration, La Brigade pour le planning et le pointage, et CodAgents pour la prospection outillée. C'est notre principale référence : nous exploitons nous-mêmes ce que nous construisons, et nous en portons les astreintes.

Ce que nous refusons : les projets où le code ne serait pas le vôtre, les périmètres au forfait sur des besoins manifestement instables, et les engagements longs sans un premier lot court qui permette aux deux parties de se juger.

Notre limite, avouée : nous sommes une petite équipe. Sur un projet exigeant plus de cinq développeurs en parallèle ou une astreinte 24 h / 24, nous ne sommes pas le bon choix, et nous le disons plutôt que de sous-traiter en cascade.

Questions fréquentes

Combien coûte un développement sur mesure ? Le marché français se situe généralement entre 400 et 900 € par jour selon la séniorité et la localisation. Le coût total dépend du périmètre : c'est pourquoi un premier lot court, chiffré précisément, vaut mieux qu'une estimation globale à six mois.

Sur mesure ou solution existante ? Si un produit du marché couvre 80 % de votre besoin, prenez-le. Le sur-mesure se justifie quand le processus qu'il outille est votre avantage concurrentiel, pas quand il est simplement inhabituel.

Combien de temps pour un MVP ? Six à douze semaines pour un premier produit utilisable par de vrais utilisateurs, si le périmètre est tenu. Le facteur qui décide n'est presque jamais la technique : c'est votre capacité à trancher vite.

Faut-il un CTO en interne ? Pas au démarrage, mais il vous faut quelqu'un capable de prioriser chaque semaine et de dire non. Sans cette personne, aucun modèle contractuel ne fonctionne.

---

Nous construisons et exploitons nos propres produits, ce qui nous oblige à écrire du code que nous devrons maintenir. Si vous voulez en discuter, écrivez-nous.