Quand une équipe recopie les mêmes informations dans trois outils différents, quand les clients réclament un accès à leurs documents, quand le tableur partagé est devenu la colonne vertébrale de l’entreprise, le sujet n’est plus le site vitrine. Il devient une question d’outillage. Cet article est un article de cadrage, pas un catalogue de technologies : il donne les signaux qui annoncent le besoin, les cas où il ne faut surtout rien développer, et la méthode pour délimiter un projet avant de le chiffrer.
Les cinq signaux qui annoncent le besoin
- La double saisie récurrente. La même information est recopiée du formulaire vers le tableur, puis du tableur vers le logiciel de facturation. Chiffrez-la honnêtement : quatre minutes par dossier, trente dossiers par semaine, cela fait deux heures hebdomadaires, soit près de treize journées par an, et autant d’occasions de se tromper.
- Les demandes clients répétitives. « Où en est ma commande ? », « pouvez-vous me renvoyer ma facture de mars ? ». Si ces deux questions occupent une personne plusieurs heures par semaine, un espace en ligne les fait disparaître presque entièrement.
- Le tableur partagé devenu critique. Il n’a ni historique, ni droits d’accès sérieux, ni contrôle de cohérence. Le jour où une formule saute ou qu’une ligne est écrasée, personne ne sait revenir en arrière. La fragilité est proportionnelle à l’importance qu’il a prise.
- Un processus métier introuvable dans le commerce. Votre façon de qualifier un dossier, de planifier une tournée ou de calculer une remise ne rentre dans aucun logiciel du marché, et vous passez votre temps à contourner l’outil que vous payez.
- Un volume qui rend le suivi manuel impossible. À partir de quelques centaines de dossiers actifs, la mémoire humaine et le tri manuel ne suffisent plus, et les oublis coûtent plus cher que l’outil.
Pour chacun de ces signaux, une seule question tranche : combien d’heures par mois le statu quo coûte-t-il réellement ? Si la réponse tient en heures, on optimise. Si elle se compte en journées, on développe.
Avant de développer : le réflexe d’assemblage
La moitié des besoins exprimés en rendez-vous se règlent sans écrire une ligne de code. Un formulaire relié à un outil de gestion, une synchronisation entre la boutique et la comptabilité, une automatisation qui crée une fiche à chaque commande : ces montages se mettent en place en quelques jours, s’ajustent facilement et ne créent aucune dette technique.
Cet assemblage montre ses limites dans quatre situations précises, et il faut savoir les reconnaître avant de s’y enfermer :
- Le coût par utilisateur devient prohibitif. Une facturation à l’utilisateur et par mois, multipliée par quinze personnes et trois outils, finit par dépasser largement un développement amorti sur trois ans.
- La dépendance à un service externe devient risquée. Changement de conditions tarifaires, arrêt d’un connecteur, fermeture du service : votre processus métier s’arrête sans que vous puissiez rien faire.
- Le processus est trop spécifique pour être modélisé. On passe alors plus de temps à contourner l’outil qu’à travailler.
- Les volumes dépassent les quotas. Les plateformes d’automatisation facturent à l’opération et plafonnent les appels. Au-delà d’un certain rythme, le montage devient à la fois cher et lent.
Les trois formes que prend un projet sur mesure
L’espace client
Documents, suivi de commande ou de dossier, factures, échanges. C’est presque toujours le meilleur rapport entre la valeur produite et la complexité technique, et c’est un excellent premier projet : le périmètre est facile à délimiter, le bénéfice se mesure en appels évités dès le premier mois, et l’outil se greffe sur le site existant sans le toucher.
L’outil métier interne
La modélisation d’un processus propre à l’entreprise : planning d’interventions, suivi de production, gestion d’un parc, qualification de dossiers. Les gains sont directs et mesurables en heures, mais le cadrage y est plus exigeant, parce qu’il faut trancher entre le processus réel et le processus rêvé.
La brique connectée
Un module qui relie le site aux outils déjà en place : gestion commerciale, comptabilité, logistique, messagerie. L’interface y est secondaire ; le vrai sujet est l’intégration, et c’est de loin la forme la plus sous-estimée en temps de développement.
Ce que React apporte, et ce qu’il n’apporte pas
Une interface riche en interactions gagne à être construite avec une bibliothèque de composants. React apporte trois choses concrètes : une gestion d’états complexes qui reste lisible quand l’écran affiche vingt éléments interdépendants, une réactivité sans rechargement de page, et des composants réutilisables d’un écran à l’autre. Pour un tableau de bord filtrable ou un formulaire à étapes conditionnelles, la différence de confort est réelle, pour l’utilisateur comme pour le développeur.
Ce que cela impose est tout aussi concret. Une chaîne de construction et de déploiement à maintenir. Des tests automatisés, sans lesquels chaque évolution devient un pari. Une attention explicite à l’accessibilité, parce qu’un composant fait maison n’est jamais accessible par défaut, contrairement à un champ de formulaire natif. Et pour toute partie publique destinée aux moteurs de recherche, un rendu côté serveur, faute de quoi le contenu risque de n’être vu par personne.
La conclusion est presque toujours la même : une page de présentation n’a aucune raison d’être une application, et un espace client n’a aucune raison d’être une page statique. Le choix de l’outil vient après le cadrage, jamais avant.
Les intégrations, là où se cache la vraie difficulté
Un projet sur mesure échoue rarement sur son interface. Il échoue sur la circulation des données entre les systèmes. Les points durs sont toujours les mêmes :
- Des formats incompatibles : dates, devises, taux de TVA, unités, encodage des caractères. Le sujet paraît trivial jusqu’au premier client dont le nom contient une apostrophe.
- Le sens de la synchronisation. Va-t-elle dans un sens, dans les deux, à quelle fréquence, et que se passe-t-il si les deux côtés changent entre deux passages ?
- Les doublons. Deux fiches pour le même client créées à trois secondes d’intervalle : il faut une clé de rapprochement décidée à l’avance, pas un nettoyage manuel tous les mois.
- La reprise après incident. Un service tiers indisponible pendant deux heures ne doit pas faire perdre les opérations de ces deux heures. Cela suppose une file d’attente, des tentatives répétées et des traitements qu’on peut rejouer sans créer de doublon.
- Les limites d’appels. La plupart des fournisseurs plafonnent le nombre de requêtes par minute. Une reprise de données de 20 000 lignes doit être découpée, sinon elle échoue au tiers.
- La sécurité des jetons d’accès. Stockage côté serveur, rotation prévue, périmètre de droits minimal. La Cnil rappelle les exigences de sécurité des données qui s’appliquent dès qu’il y a des données personnelles, et il y en a presque toujours.
Une seule règle évite la majorité des désordres constatés : pour chaque donnée, décidez quelle application fait autorité. L’adresse de facturation vient de la comptabilité, le statut de commande vient de la boutique, la fiche client vient du logiciel de gestion. Écrivez-le noir sur blanc avant la première ligne de code, et les conflits de synchronisation disparaissent d’eux-mêmes.
Cadrer avant de chiffrer
Un projet sur mesure se cadre en quatre gestes, et cela prend rarement plus d’une semaine.
- Lister les utilisateurs et leurs tâches. Qui se connecte, pour faire quoi, combien de fois par semaine. Trois profils suffisent souvent.
- Écrire les parcours en phrases simples. « Un client se connecte, voit ses trois derniers dossiers, télécharge une facture. » Si la phrase ne s’écrit pas, la fonctionnalité n’est pas mûre.
- Séparer l’indispensable du confortable. Deux colonnes, et une discipline : tout ce qui n’est pas indispensable passe en version suivante.
- Écrire ce qui ne sera pas fait. C’est la partie la plus utile du document, et celle que personne ne rédige.
Visez ensuite une première version volontairement réduite, mise en service rapidement, plutôt qu’un périmètre complet livré dans un an. Un outil utilisé par cinq personnes pendant six semaines apprend plus sur le besoin réel que six mois d’ateliers. Les délais réels d’un projet web donnent les ordres de grandeur à retenir pour construire ce calendrier.
Notre position : vivre avec une application sur mesure
Les pages commerciales s’arrêtent à la livraison. C’est précisément là que commence la partie coûteuse si elle n’a pas été prévue. Une application se met à jour, se sauvegarde, se supervise et évolue avec l’entreprise. Les bibliothèques du front vieillissent vite : une base laissée deux ans sans mise à jour se reprend au prix fort, alors que le même travail étalé au fil de l’eau reste marginal.
Trois exigences sont non négociables de notre côté, et vous devriez les poser à n’importe quel prestataire. Le code vit dans un dépôt de code à votre nom, auquel vous avez accès. La procédure de déploiement est documentée, de sorte qu’une autre équipe puisse reprendre le travail. Les sauvegardes et la supervision sont en place dès la mise en service, pas ajoutées après le premier incident. Ce sont les mêmes questions que celles à poser pour choisir son agence web, avec des enjeux plus élevés. Le maintien en conditions opérationnelles se traite ensuite par suivi et maintenance applicative. Quand le besoin porte surtout sur la façade publique d’un site déjà bien administré, la question à se poser est différente et se pose du côté de l’architecture découplée.
Questions fréquentes
Faut-il refaire le site pour ajouter un espace client ?
Non. L’espace se greffe sur le site existant, généralement sur un sous-domaine dédié, avec sa propre authentification. Le site vitrine continue de vivre sa vie sans être touché.
Sur mesure ou logiciel du marché ?
Le marché d’abord, systématiquement. Le sur mesure se justifie quand le processus constitue un avantage concurrentiel, quand aucun éditeur ne le couvre, ou quand le coût par utilisateur d’une solution existante devient déraisonnable à votre échelle.
Qui est propriétaire du code produit ?
Le client, avec accès au dépôt et documentation de déploiement. C’est à écrire dans le devis, pas à découvrir à la fin. Un prestataire qui refuse cette clause vous vend une dépendance, pas un outil.
Peut-on commencer petit ?
Oui, et c’est recommandé. Une première version restreinte réellement en service vaut mieux qu’un projet complet jamais livré. Elle valide le besoin, révèle les vrais points durs et finance la suite.
Ce qu’il faut retenir
Le sur mesure n’est pas un luxe, c’est un arbitrage : on développe quand le processus est spécifique et que le temps perdu se compte en journées par mois. Avant tout devis, chiffrez le coût du statu quo pendant deux semaines, en heures réellement passées. Ce chiffre décidera du projet mieux que n’importe quel argumentaire.
À lire aussi : site vitrine ou boutique en ligne, quelle solution choisir
