Logiciels métier conçus autour de vos usages réels
La plupart des entreprises ne souffrent pas d’un manque de logiciels. Elles souffrent de logiciels qui ne parlent pas entre eux, et de tableurs qui font tenir le reste.
- Nature
- Application interne, back-office, outil métier
- Périmètre
- Cadrage · produit · interfaces · architecture
- Socle
- TypeScript · PostgreSQL · API documentée
- Propriété
- Code, données et documentation livrés
Pourquoi le tableur finit toujours par revenir
Un progiciel impose son modèle. Quand votre métier s’en écarte — et il s’en écarte toujours quelque part — les équipes inventent des contournements : un tableur parallèle, une colonne détournée, un dossier partagé, une convention de nommage que seule une personne connaît.
Ces contournements sont la meilleure spécification qui existe. Ils décrivent exactement ce que l’outil officiel ne sait pas faire, et ce que le métier fait vraiment. Nous commençons toujours par les recenser.
Le but n’est pas de tout remplacer. C’est de construire l’outil qui manque, connecté à ceux qui fonctionnent déjà, et de supprimer les doubles saisies qui coûtent le plus cher — en temps comme en erreurs.
De l’observation à la mise en production
- 01
Comprendre
Nous regardons travailler. Les flux réels, les rôles, les cas particuliers, les contraintes réglementaires, les moments où ça coince. Un cadrage sérieux vaut trois mois de développement mal orientés.
- 02
Prototyper
Des maquettes manipulables sur les écrans qui portent la valeur, avant le code. Une interface se juge en l’utilisant, pas en la décrivant — et un prototype rejeté coûte une semaine, pas un trimestre.
- 03
Construire
Une architecture explicite : modèle de données défendable, règles métier au bon endroit, API documentée, tests sur ce qui casse cher. L’objectif est qu’un autre développeur puisse reprendre le projet.
- 04
Déployer et suivre
Mise en production progressive, formation, observation de l’usage. Les six premières semaines révèlent toujours des choses que personne n’avait dites : on les corrige à ce moment-là.
Nos règles de travail
- Le périmètre est écrit et négociable ; ce qui est reporté est dit, pas oublié.
- Vous voyez tourner quelque chose de réel toutes les deux semaines, pas un rapport d’avancement.
- Les données sont modélisées pour durer : c’est ce qui coûte le plus cher à corriger après coup.
- La documentation fait partie de la livraison, pas d’une option.
- Vous restez propriétaire du code et de la base, et libre de changer de prestataire.
Ce qu’on nous demande le plus souvent
Les réponses que nous donnons de toute façon au premier échange.
Comment savoir si le sur-mesure est justifié ?
Trois signaux : vos équipes maintiennent des tableurs pour compenser l’outil officiel, vous payez des licences pour des fonctions que vous n’utilisez pas, ou une règle centrale de votre métier est impossible à exprimer dans le progiciel. Si aucun ne s’applique, restez sur l’existant.
Peut-on reprendre nos données actuelles ?
Oui, c’est même une étape à part entière : extraction, nettoyage, correspondance des modèles, reprise vérifiée. Une migration bâclée fait échouer un projet techniquement réussi.
Que se passe-t-il si nous changeons de prestataire ?
Rien de bloquant, à condition que ce soit prévu dès le départ : code versionné et livré, base standard, API documentée, procédure de déploiement écrite. C’est notre mode de travail par défaut.
Travaillez-vous avec nos développeurs internes ?
Oui, fréquemment : en renfort sur une partie du produit, en reprise d’un existant, ou en cadrage et architecture avec exécution interne. Le mode se décide selon vos ressources.
Un outil métier à construire ou à reprendre ?
Parlez-nous du problème, pas du cahier des charges. Nous cadrons ensemble ce qui se justifie.
Parler de votre projet Réponse sous deux jours ouvrés · contact@anym.fr