Service
Développement d'applications web sur mesure
Des plateformes qui tiennent sous une charge réelle, des données réelles et de vrais utilisateurs.
Le web est là où vit l'essentiel de ce que nous construisons : plateformes internes qui font tourner une activité, portails clients, tableaux de bord sur des données d'exploitation réelles, et sites publics qui doivent être rapides et trouvables. Construits comme des applications plutôt qu'assemblés à partir d'extensions, ce qui est précisément ce qui les rend encore modifiables un an plus tard.
La décision
Quand c'est le bon choix.
La décision oppose rarement le sur-mesure au néant. Elle oppose le sur-mesure à une plateforme plus les extensions nécessaires pour combler l'écart entre ce qu'elle fait et ce qu'il vous faut. Cet empilement est peu cher à démarrer et cher à posséder : chaque extension est une dépendance, un coût de performance et une surface d'attaque, et l'ensemble casse à la prochaine version majeure de la plateforme.
Le deuxième coût, c'est le plafond. Les projets sur plateforme vont vite jusqu'au premier besoin que la plateforme ne peut pas exprimer, et alors le contournement devient l'architecture. Les entreprises finissent par se réorganiser autour de leur logiciel au lieu de l'inverse, soit exactement la situation que l'achat du logiciel devait éviter.
Le sur-mesure vaut son coût quand la logique métier est le produit, quand le modèle de données est réellement le vôtre, ou quand la performance et l'intégration comptent assez pour devenir des décisions d'ingénierie. Quand rien de cela n'est vrai, nous le disons — une plateforme bien choisie est une meilleure réponse qu'un projet que nous aurions pris plus de plaisir à faire.
Ce que vous obtenez
Ce que couvre la mission.
Une architecture qui tient à la croissance
Modèle de données, frontières et déploiement décidés avant le premier écran, car ce sont les choix dont le retour en arrière coûte cher.
Rendu côté serveur là où cela compte
Des pages qu'un robot et un téléphone lent reçoivent complètes, l'interactivité venant par-dessus au lieu de conditionner l'apparition du contenu.
Autorisation réelle
Les droits sont appliqués côté serveur à chaque requête, pas en masquant des entrées de menu. Et vérifiés par des tests qui cherchent à les contourner.
La performance comme budget chiffré
Les Core Web Vitals sont traités comme une contrainte de build chiffrée, et non comme un rapport lancé après la mise en service.
Accessibilité intégrée dès le départ
Parcours clavier, gestion du focus, contraste et sémantique dès le premier composant, ce qui coûte moins cher qu'un rattrapage et sert aussi le référencement.
Exploitable en production
Journalisation, remontée d'erreurs, sauvegardes et restauration répétée, car un logiciel qu'on ne peut pas exploiter n'est pas terminé.
Stack
Avec quoi nous le construisons.
Choisis projet par projet. Rien n'est imposé par défaut ici, et l'équipe qui assurera la maintenance pèse autant que le problème.
Frontend
TypeScript avec React ou des gabarits rendus côté serveur, choisis projet par projet. Aucun framework n'est imposé par défaut.
Backend
Python, Node ou .NET, choisis autant en fonction de l'équipe qui les maintiendra que du problème.
Données
PostgreSQL ou MySQL, avec un schéma conçu et non généré. Redis là où le cache aide réellement.
Infrastructure
Linux, nginx, conteneurisé là où cela vaut sa complexité — sur votre cloud ou le nôtre.
Livraison
Gestion de versions, tests automatisés et chaîne de déploiement dès le premier jour, pas ajoutés quand cela fait mal.
Comparaison
Build sur plateforme ou développement sur mesure.
La comparaison qu'il faut faire avant de confier quoi que ce soit. Pour une bonne part des projets, c'est la colonne de gauche qui l'emporte, et nous le dirons.
| Critère | Plateforme + extensions | Développement sur mesure |
|---|---|---|
| Délai avant d'avoir quelque chose d'utilisable | Quelques jours. C'est un avantage réel, et souvent décisif. | Des semaines. Justifié seulement quand la plateforme ne peut pas exprimer ce qu'il vous faut. |
| Structure du coût | Faible et récurrent : licence, croissance par utilisateur, abonnement par extension, partenaire d'intégration | Élevé et ponctuel, puis l'hébergement. Le code vous appartient, sans licence d'exécution. |
| Le plafond | Atteint au premier besoin que la plateforme ne peut pas exprimer ; le contournement devient alors l'architecture | Fixé par vos propres choix de conception, pas par la feuille de route d'un tiers |
| Surface de dépendances | Chaque extension est du code que vous n'avez pas écrit, avec son propre cycle de publication, à l'intérieur de votre périmètre de sécurité | Uniquement les bibliothèques que vous avez choisies, revues et figées |
| Montées de version majeures | Ce qui casse, c'est la combinaison d'extensions, et elle casse au calendrier d'un autre | Vous décidez du moment, et les tests vous disent ce qui a bougé |
| Performance et Core Web Vitals | Le poids du thème et des extensions, traité en ajoutant une extension de cache | Une contrainte de build assortie d'un chiffre, imposée dans le pipeline |
Comment cela se déroule
De la première conversation à la mise en ligne.
Indicatif pour un travail de cette nature. Le pilote n'est pas optionnel — rien n'est basculé tant que les utilisateurs n'ont pas dit que cela tient.
- 1 à 2 semaines
Cadrage
Nous modélisons d'abord les données et les rôles. C'est là que se trouve réellement le coût, et là que les projets sur plateforme dérapent le plus souvent — pas dans les écrans.
- 4 à 8 semaines
Développement du socle
Le chemin le plus fréquenté de bout en bout, avec vos vraies données et une chaîne de déploiement dès la première semaine, pas quand cela fait mal.
- 2 à 3 semaines
Pilote
Une équipe l'utilise pour du travail réel pendant que l'ancien processus continue. Chaque manque qu'elle rencontre est corrigé avant que quiconque d'autre ne bascule.
- 1 à 2 semaines
Mise en service et transfert
Les utilisateurs restants, la supervision et des sauvegardes à restauration répétée, avec la documentation qui permet à un autre développeur de reprendre.
Après la mise en service
Ce qui change.
- Le besoin que la plateforme ne pouvait pas exprimer cesse d'être traité par une personne dans un tableur.
- La performance des pages devient un chiffre que vous tenez, et non une extension dont vous espérez qu'elle agit.
- Les montées de version cessent d'être un événement, faute de combinaison d'extensions à casser.
- Une modification souhaitée en semaine soixante coûte à peu près ce qu'elle aurait coûté en semaine six.
Décrit qualitativement à dessein. Nous ne publions pas de pourcentages d'amélioration que nous ne pouvons pas rattacher à un client nommé, avec son accord.
Questions
Questions fréquentes.
Combien de temps prend une application web sur mesure ?
Une plateforme interne ciblée demande en général huit à quatorze semaines entre la première conversation et la production. Les systèmes plus vastes et multi-modules prennent plus de temps et sont livrés par étapes, le premier module étant en service pendant que le suivant se construit — nous préférons que vous utilisiez tôt quelque chose de réel plutôt que d'attendre l'ensemble.
Sommes-nous propriétaires du code ?
Oui, entièrement, y compris le dépôt et la configuration de déploiement. Il n'y a aucune licence d'exécution ni rien qui empêche un autre développeur de reprendre.
Pouvez-vous travailler avec notre système existant ?
En général, oui. La plupart des projets commencent par s'intégrer à l'existant — un logiciel comptable, un ERP, une base de données ancienne. Tout remplacer d'un coup est rarement le bon choix, et une approche par étapes est plus sûre.
Que se passe-t-il après la mise en service ?
Une période de support est incluse ; ensuite, la plupart des clients optent pour un forfait de maintenance couvrant évolutions et supervision. Ni l'un ni l'autre ne vous enferme : le code vous appartient et il est suffisamment documenté pour qu'un tiers le reprenne.
Ne devrions-nous pas simplement prendre une plateforme ?
Souvent, oui. Si votre modèle de données entre dans la plateforme et que le logiciel n'est pas ce qui vous différencie, la plateforme est plus rapide et moins chère et nous vous le dirons. Le sur-mesure gagne sa place quand la logique métier est le produit, quand le modèle de données est réellement le vôtre, ou quand l'intégration et la performance sont des problèmes d'ingénierie et non des réglages.
Que se passe-t-il si nos besoins changent en cours de route ?
Elles changeront, et le plan le suppose. Les phases sont réestimées à chaque jalon avec ce qui a été appris, et c'est pourquoi nous préférons un prix plafonné par phase à un prix fixe sur l'ensemble du périmètre — ce dernier est soit gonflé pour le risque, soit voué au litige au premier changement.