S3 · Service
Une application métier qui fait exactement ce dont votre équipe a besoin
Outils internes, back-offices, automatisation des tâches que quelqu’un fait encore à la main. Construite en C# / .NET, pensée pour durer et pour être reprise par quelqu’un d’autre que moi.
- Livrables
- API REST
- Back-office
- Base de données
- Automatisation
- Documentation
Quand le sur-mesure est la bonne réponse, et quand il ne l’est pas
Un logiciel du marché est presque toujours moins cher au départ. Il devient plus cher le jour où votre façon de travailler ne rentre plus dans ses cases : contournements, doubles saisies, exports vers Excel, modules payants qui ne font pas tout à fait ce qu’il faut. Trois questions tranchent en général.
- Votre processus est-il standard ? Si dix concurrents font pareil, un outil du marché existe et il est bon. Si votre façon de faire est votre avantage, le sur-mesure la protège.
- Combien de personnes l’utilisent ? À partir d’une quinzaine d’utilisateurs, les licences d’un outil du marché dépassent souvent le coût d’un développement sur trois ans.
- Qui le fera évoluer ? Le sur-mesure demande quelqu’un pour le maintenir. Si personne ne peut s’en occuper, il faut le prévoir dès le devis, pas le découvrir après.
Il existe une troisième voie, souvent la meilleure : du sur-mesure autour d’un outil que vous avez déjà. L’outil de prospection construit dans SharePoint en est un exemple : aucun serveur, aucun abonnement, et l’environnement que les équipes utilisaient déjà.
Ce que je livre
Une application web ou Windows
En ASP.NET Core pour le web, en .NET pour Windows. Des écrans sobres qui chargent vite, des formulaires qui valident au bon moment, des tableaux qu’on peut trier et exporter. Rien de spectaculaire, et c’est voulu : une application métier se juge au nombre de clics économisés.
Une API et une base de données
Le modèle de données est la décision la plus importante du projet, celle qu’on paie le plus cher quand elle est mauvaise. J’y passe le temps qu’il faut au début. L’API qui l’expose est écrite pour que d’autres outils, ou une application mobile plus tard, puissent s’y brancher.
L’automatisation des tâches répétitives
Rapports générés au lieu d’être remplis, imports au lieu de saisies, notifications au lieu de relances manuelles. C’est souvent là que se trouve le retour sur investissement le plus rapide : des heures par semaine rendues à une équipe. Le cas desrapports de mesures montre ce que ça donne concrètement.
La documentation et le transfert
Le code vous appartient, il est documenté au fil du projet, et il est écrit pour qu’un autre développeur .NET puisse le reprendre. Une application qui ne peut être maintenue que par son auteur est une dette, pas un actif.
Comment se passe un projet
Toujours le même déroulé, en quatre temps : comprendre le besoin avant de parler technique, arbitrer les compromis ensemble, construire par incréments visibles, puis mettre en production et transférer. Le détail est sur la page d’accueil. Ce qui compte : vous voyez quelque chose qui fonctionne toutes les deux ou trois semaines, pas à la fin.
Ce que ça coûte : comment je chiffre
Aucun prix sérieux ne se donne sans dix questions. Ce qui fait le coût d’une application métier, ce sont les écrans, le nombre de règles métier, les intégrations avec l’existant, la reprise des données déjà là, et ce qu’il faut pour l’exploiter. Après un premier échange, je donne un ordre de grandeur en jours. Après un cadrage écrit, un devis. Au forfait quand le périmètre est clair, à la journée quand il ne l’est pas encore.
Ce que je ne fais pas
- Sites vitrines, WordPress, e-commerce : ce sont des métiers, ce ne sont pas les miens.
- Design et maquettes : je travaille avec les vôtres ou avec un designer.
- Applications mobiles natives : je construis le backend qu’elles appellent, pas l’application elle-même.
- Réécrire un système de zéro « parce que ce serait plus propre » : presque toujours une mauvaise idée, et je le dis.
Questions fréquentes
- Application web ou application Windows ?
- Ça dépend de qui l’utilise et d’où. Une équipe sur des postes fixes, avec des appareils ou des fichiers locaux, est souvent mieux servie par une application Windows. Des utilisateurs dispersés, sur plusieurs appareils, par une application web. Je construis les deux en .NET, et la question se tranche au premier échange, pas au devis.
- Combien de temps prend une application métier ?
- De quelques semaines pour un outil interne ciblé à plusieurs mois pour un back-office complet avec intégrations. L’ordre de grandeur se donne après un premier échange ; le devis, après un cadrage écrit. Jamais avant.
- Et l’interface ? Vous faites aussi le front ?
- Pour une application métier, oui : écrans, formulaires, tableaux, en restant sobre et rapide. Ce que je ne fais pas, c’est du design de marque ou de la maquette créative. Si votre projet en demande, je travaille avec votre designer.
- Travaillez-vous à distance ?
- Oui, avec des entreprises de toute la France. Sur site en Nouvelle-Aquitaine quand le projet le demande, ponctuellement ailleurs.
- Je n’ai pas de cahier des charges. C’est un problème ?
- Non. La première étape d’une mission consiste précisément à comprendre le besoin et à l’écrire. Décrivez le problème avec vos mots, le reste est mon travail.
- Qui possède le code ?
- Vous. Le code, la documentation et les accès vous sont remis au fil de la mission, pas à la fin. Vous pouvez confier la suite à quelqu’un d’autre à tout moment.
- Comment facturez-vous ?
- Au forfait quand le périmètre est clair, à la journée quand il ne l’est pas encore. Dans les deux cas, un devis écrit avant de commencer, et pas de surprise après.