Les questions qu’on nous pose vraiment

Parce qu'un prix affiché sans périmètre ne veut rien dire, et qu'il finit toujours par être faux dans un sens ou dans l'autre. Ce qui fait le prix d'un projet, ce sont les raccordements à vos outils existants et la reprise de vos données — pas un nombre de pages. Nous donnons une fourchette au premier échange, gratuitement, et un chiffrage ferme à l'issue du cadrage.

Non. Le premier rendez-vous sert à qualifier : ce que vous voulez obtenir, dans quels délais, avec quelles contraintes. Si votre besoin n'est pas dans nos cordes, nous vous le disons, et nous orientons quand nous pouvons. C'est le cadrage, qui vient après et produit un périmètre chiffré, qui est une prestation facturée.

Le no-code convient tant que l'application reste dans les rails de la plateforme : peu d'utilisateurs simultanés, logique métier simple, peu d'intégrations, aucune contrainte forte de performance ou de conformité. La frontière ne se situe pas au niveau de la complexité apparente mais du modèle de données : dès qu'il devient relationnel et contraint, le no-code coûte plus cher qu'un développement classique. Le bon usage est de valider vite un besoin en no-code, puis de reconstruire ce qui a trouvé son public.

Achetez un logiciel du marché si votre besoin est standard — c'est presque toujours moins cher, même en s'adaptant un peu. Développez sur mesure quand le processus concerné vous différencie de vos concurrents. Externalisez quand vous avez besoin de la compétence sans vouloir la recruter durablement. La question à trancher d'abord n'est pas « qui code ? » mais « ce processus fait-il partie de ce qui nous distingue ? ».

Le forfait convient quand le périmètre est stable et documenté : le prestataire porte le risque de dérive, et vous payez cette assurance dans le prix. La régie convient quand le besoin évoluera en cours de route : vous payez des jours et vous portez le risque, ce qui suppose d'avoir quelqu'un pour piloter. Le centre de services est un compromis pour une relation durable : une capacité récurrente avec des engagements de résultat sur le service rendu. Le mauvais choix n'est jamais le modèle en soi, c'est le décalage entre le modèle et la maturité du besoin.

Sept points : la cession des droits sur le code (intégrale et sans condition), la documentation comme livrable contractuel, les conditions de réversibilité, la définition précise de la recette et de ses délais, le traitement des demandes de changement, les engagements de service après mise en production, et la propriété des données. L'absence d'une seule de ces clauses peut vous coûter plus cher que l'écart de prix entre deux prestataires.

En additionnant quatre postes rarement mesurés : le temps passé sur des tâches manuelles évitables, le coût des erreurs et de leur rattrapage, les occasions perdues faute de réactivité, et le risque de dépendance à une personne ou à un fichier unique. Ce coût est invisible parce qu'il est réparti et n'apparaît sur aucune ligne budgétaire — mais il se reconduit chaque année et augmente avec l'activité.

En chiffrant le coût de la situation actuelle avant de parler du coût du projet. Une direction ne compare pas un devis à zéro : elle compare deux coûts. Le dossier tient en une page — ce que la situation actuelle coûte chaque année, ce que le projet coûte en investissement et en fonctionnement, à partir de quand l'un compense l'autre, et ce qui se passe si l'on ne fait rien pendant deux ans.

Le code, la documentation et les procédures d'exploitation vous appartiennent. Les accès — hébergement, nom de domaine, dépôt de code, comptes tiers — sont à votre nom, pas au nôtre. Vous pouvez reprendre la main ou partir ailleurs sans rien nous redemander. C'est ce qui nous oblige à bien faire, et c'est écrit au contrat.

Oui. Sur un site vitrine ou une boutique, vous tenez les textes, les images, le catalogue et les prix depuis une interface d'administration, et la prise en main est incluse. Ce qui reste chez nous, c'est ce qui casse un site quand on y touche sans filet : les montées de version, la sécurité et les sauvegardes.

Par un audit de deux à trois semaines avant tout engagement : capacité à reconstruire l'application depuis zéro, état des dépendances et des failles connues, couverture de tests, accès aux environnements, et qualité de la reprise de données. Le critère décisif n'est pas la propreté du code mais la capacité à déployer une correction en production en moins d'une journée. Tant qu'on ne sait pas faire ça, on ne peut pas s'engager sur des délais de rétablissement.

Mesurez-la par ses effets, pas par des métriques de code : temps moyen pour livrer une correction, proportion de modifications qui causent une régression, temps de reconstruction et de déploiement, et nombre de dépendances non maintenues. Financez-la par une allocation permanente — nous réservons 15 à 20 % de la capacité de chaque itération — plutôt que par des chantiers exceptionnels, qui sont toujours reportés.

Quatre signaux suffisent pour l'essentiel : le taux d'erreur, le temps de réponse des parcours critiques, la saturation des ressources, et le volume de trafic. À cela s'ajoutent des indicateurs métier — commandes créées, paiements aboutis — souvent plus révélateurs qu'une métrique technique. Une alerte qui se déclenche sans action possible sera ignorée : mieux vaut trois alertes qui réveillent quelqu'un que trente que personne ne regarde.

Huit points, avant toute mise en production : l'authentification déléguée à un composant éprouvé, un contrôle d'accès vérifié côté serveur sur chaque requête, le cloisonnement des données entre organisations, le chiffrement en transit et au repos, la journalisation des accès sensibles, la gestion des secrets hors du code, les mises à jour de dépendances automatisées, et une procédure de restauration testée. Aucun de ces points n'est exotique : ce sont les mêmes failles que l'on retrouve année après année.

Dans l'Union européenne par défaut, et nous vous disons chez quel hébergeur avant de commencer. Quand un projet impose un service hors UE — un modèle d'IA, un prestataire de paiement — nous le signalons au cadrage, avec ce que cela implique, plutôt que de le découvrir au moment du registre des traitements.

Cinq familles suffisent à couvrir l'essentiel : la fraîcheur (les données sont-elles arrivées ?), la volumétrie (en quantité attendue ?), la complétude (les champs obligatoires sont-ils remplis ?), la validité (les valeurs respectent-elles leur format et leur domaine ?) et la cohérence entre sources (les totaux se recoupent-ils ?). Ces contrôles tournent à chaque rafraîchissement et alertent avant les utilisateurs. Ce qui change la perception de fiabilité n'est pas l'absence d'erreur — c'est le fait d'être prévenu avant celui qui consulte le tableau de bord.

Trois environnements suffisent : développement local, préproduction identique à la production, et production. Le déploiement doit être automatisé, reproductible et déclenché par une seule commande, avec un retour arrière possible en quelques minutes. Le critère qui résume tout : combien de temps faut-il pour mettre une correction d'une ligne en production ? Tant que la réponse dépasse une journée, tous les engagements de délai sont théoriques.