Développement web sur mesure à Paris

Le sur-mesure devient pertinent lorsqu’un processus, un calcul, un configurateur, des droits ou des intégrations ne peuvent pas être couverts proprement par une solution existante. Le cadrage vérifie d’abord si une configuration ou une extension suffit avant d’engager une construction spécifique.

En pratique, trois signaux le justifient. Le premier est le nombre de règles conditionnelles : un devis dont le prix dépend de six paramètres qui interagissent ne se paramètre pas dans un formulaire de module, il s’écrit. Le deuxième est la structure des droits : dès que trois profils voient des données différentes de la même fiche, les systèmes de rôles des CMS deviennent des empilements d’exceptions. Le troisième est l’intégration : un aller-retour avec un ERP qui doit gérer les échecs, les reprises et l’ordre des opérations demande du code, pas un connecteur générique.

À l’inverse, trois demandes n’ont presque jamais besoin de sur-mesure : un catalogue de moins de deux cents produits sans configuration, un site éditorial même volumineux, et une prise de rendez-vous standard. Nous le disons au cadrage, quitte à proposer un projet plus petit que celui qui nous était demandé.

Le budget découle des rôles, règles métier, parcours, données, intégrations, exigences de sécurité, besoins de 2D ou 3D et conditions d’exploitation. Le devis distingue le premier socle fonctionnel, les options et les hypothèses qui peuvent faire évoluer le projet.

Le poste qui surprend le plus n’est pas le développement des écrans mais tout ce qui entoure les cas non nominaux. Un formulaire qui fonctionne quand tout va bien se code en deux jours ; le même formulaire avec la reprise après coupure, la validation côté serveur, les messages d’erreur compréhensibles, les droits et la trace de qui a modifié quoi en demande cinq. Les projets qui dérapent ont presque tous sous-estimé cette part, et c’est pour cela qu’elle figure ligne par ligne au devis.

Les intégrations sont l’autre inconnue, parce qu’elles dépendent d’un système que nous ne maîtrisons pas. Nous chiffrons une connexion à un outil dont la documentation est publique et l’environnement de test accessible ; quand ce n’est pas le cas, la ligne porte une hypothèse explicite et un plafond, plutôt qu’un chiffre qui ne veut rien dire.

Oui. Un premier lot peut se concentrer sur un processus cohérent de bout en bout. Il doit toutefois inclure les données, droits, erreurs et conditions d’exploitation nécessaires pour être utilisé réellement, pas seulement démontré.

La distinction est importante parce qu’elle décide de ce que le premier lot prouve. Un lot qui couvre un parcours complet — saisir, valider, consulter, corriger — met le produit entre les mains de ses utilisateurs et fait remonter les exceptions que personne n’avait formulées. Un lot qui couvre la moitié de trois parcours ne prouve rien : il ne peut pas être utilisé, donc il ne peut pas être corrigé par l’usage.

Deux choses ne se reportent jamais au lot suivant. Le modèle de données, parce que le refaire ensuite oblige à migrer ce qui a déjà été saisi. Et les droits, parce qu’un produit ouvert à tous en phase un ne se referme pas sans revoir chaque écran.

Le découpage est écrit au devis avec ce que chaque lot rend possible et ce qu’il laisse de côté. C’est aussi ce qui permet d’arrêter après le premier si le besoin s’est révélé différent.

Le choix vient après le modèle produit, les intégrations, les compétences d’exploitation et les contraintes de performance ou de sécurité. Nous privilégions un socle maîtrisé et maintenable plutôt qu’une technologie choisie pour son effet d’annonce.

Concrètement : Laravel ou Symfony portent la logique métier, les droits et les échanges avec vos systèmes ; React n’apparaît que là où l’interface est réellement interactive — un configurateur, un tableau de bord qui se met à jour, une saisie complexe. Un back-office classique n’en a pas besoin, et lui en imposer un ajoute une couche à maintenir sans rien apporter à l’utilisateur.

Entre Laravel et Symfony, la question n’est pas technique mais d’exploitation : Symfony impose plus de structure et se tient mieux sur un produit à longue durée de vie avec plusieurs développeurs ; Laravel avance plus vite sur un périmètre qui doit sortir en quelques mois. Nous vous disons lequel nous recommandons et pourquoi.

Une contrainte pèse plus que toutes les autres : qui reprendra le code. Un socle rare vous enferme chez son prestataire, quelle que soit sa qualité.

Oui après audit du code, des dépendances, des environnements, des données et des procédures. L’audit distingue ce qui peut être conservé, sécurisé, refactoré ou remplacé et explicite les zones à risque.

Cet audit prend de deux à cinq jours selon la taille et produit un document qui vous appartient, même si vous ne poursuivez pas avec nous. Il regarde six choses : la version du langage et du cadriciel et leur fenêtre de support, l’état des dépendances et celles qui sont abandonnées, la présence de tests automatisés, la façon dont les secrets sont stockés, la reproductibilité de l’environnement, et l’existence d’une procédure de restauration testée.

Deux situations nous font refuser la reprise. Un code non fourni ou incomplet, parce que nous serions responsables d’un système que nous ne pouvons pas lire. Et une base de production sans environnement de test, parce que la première correction se ferait directement sur les données de vos clients.

Quand la reprise est possible, le premier lot est presque toujours le même : rendre l’environnement reproductible et la restauration testée. Rien d’autre n’est sûr avant.

Les règles d’accès, les journaux, la gestion des secrets, le chiffrement en transit, les sauvegardes testées et les procédures de restauration sont définis pendant la conception, pas ajoutés après la mise en production.

Le contrôle des droits est vérifié côté serveur, à chaque requête. Un écran masqué dans l’interface n’est pas une protection : l’adresse reste appelable, et c’est par là que passent la plupart des fuites sur les applications métier. Nous testons cela explicitement en recette, en appelant les points d’entrée avec un compte qui ne devrait pas y avoir accès.

Les secrets — mots de passe de base, clés d’API, jetons — ne vivent jamais dans le dépôt de code. Ils sont injectés par l’environnement, et leur rotation est une procédure écrite, pas une opération improvisée le jour où quelqu’un part.

Les journaux consignent qui a fait quoi et quand sur les données sensibles. C’est une exigence du RGPD dès qu’il y a des données personnelles, et c’est surtout la seule façon de répondre à la question « qui a modifié cette fiche » six mois plus tard.

Les scénarios sont écrits à partir des usages réels, testés sur un environnement de préparation, avec les rôles et les données représentatives. Les anomalies, les décisions et les écarts acceptés sont consignés avant la mise en production.

La recette d’une application métier ne se fait pas par le chef de projet seul : elle demande les personnes qui utiliseront l’outil, sur leurs propres cas, y compris les cas tordus qu’elles connaissent et que personne n’a écrits. Comptez deux à quatre demi-journées selon le périmètre, réparties sur deux semaines pour laisser le temps aux corrections.

Les données de test comptent autant que les scénarios. Une application recettée sur dix fiches propres passe ; la même avec trois mille lignes dont certaines incomplètes révèle les lenteurs, les tris qui n’en sont pas et les écrans qui débordent. Nous demandons donc un extrait représentatif de vos données réelles, anonymisé si nécessaire.

Ce qui est consigné à la fin n’est pas la liste des anomalies corrigées mais celle des écarts acceptés : ce qui a été renoncé, par qui, et pourquoi. C’est ce document qu’on relit dans un an.

Le code source, l’accès aux environnements, la documentation technique et fonctionnelle, les procédures d’exploitation et de restauration, ainsi que la formation prévue au contrat pour les administrateurs et les utilisateurs concernés.

Dans le détail, l’inventaire de livraison comprend le dépôt avec son historique complet — pas une archive du dernier état —, les comptes d’administration, les variables d’environnement documentées sans leurs valeurs secrètes, la procédure de déploiement, la procédure de restauration avec la date de son dernier test, le schéma de données, et la liste des dépendances externes avec leur titulaire de licence.

La documentation fonctionnelle décrit les règles métier telles qu’elles ont été codées, ce qui n’est pas toujours ce qui avait été demandé au départ : les arbitrages de la recette y figurent. C’est cette partie qui sert à la personne qui reprendra l’outil.

La formation se tient avant la mise en production, pas après, et son support vous reste. Une passation faite le jour du lancement, dans l’urgence, ne se retient pas.