Le travail vit dans des tableurs
Plusieurs personnes modifient une même feuille Google, les versions divergent et personne ne peut restaurer l'historique.
Espaces clients, CRM internes, calculateurs de devis, panneaux de gestion avec rôles. Un seul outil à la place des tableurs et des échanges de mails.
Plusieurs personnes modifient une même feuille Google, les versions divergent et personne ne peut restaurer l'historique.
Un manager calcule le devis ou le prix dans un calculateur en suivant une consigne. Les erreurs arrivent, la vitesse dépend de la personne.
Vous avez regardé plusieurs CRM : chacun a 80 % de superflu et il manque les 20 % nécessaires. Ou ils existent, mais au prix d'un projet à part.
Statut de commande, documents, historique — tout doit être demandé à un manager, qui y passe la moitié de sa journée.
Une partie dans le CRM, une partie dans la comptabilité, une partie dans la messagerie. Impossible d'assembler une vue d'ensemble.
Votre outil est utile au-delà de vous — et vous pensez abonnement, offres et comptes séparés pour les clients.
Propriétaire, manager, client, sous-traitant — chacun voit ce qui le concerne.
Par service, agence ou projet.
Qui a modifié quoi et quand — avec possibilité d'annuler.
Si nécessaire, pour les rôles ayant accès à l'argent et aux données personnelles.
Une structure pour vos entités, pas pour un modèle étranger.
Tiennent des centaines de milliers d'enregistrements sans ralentir.
Reprise de ce qui vit aujourd'hui dans Excel et Google Sheets.
Les mêmes que celles du manager aujourd'hui, mais sans erreurs.
Par responsable, statut, activité.
Selon votre modèle, pas un tableau standard.
Contrats, factures, procès-verbaux — directement à partir des données du système.
En page d'accueil, pour ne pas reconstituer la situation à la main chaque matin.
Telegram, e-mail, SMS — selon ce qui vous convient.
CRM, gestion des stocks, comptabilité.
S'il s'agit d'un SaaS — offres tarifaires et prélèvements récurrents.
Pour une application mobile ou des partenaires.
Pas « ce que le système doit savoir faire », mais comment le travail est organisé aujourd'hui : qui fait quoi, d'où viennent les données, où le temps se perd. Souvent, la moitié des souhaits tombe dès cette étape. 3–5 jours.
Un schéma cliquable des écrans : la logique, les transitions et les données sont visibles. Changer quelque chose ici coûte des heures, pas une semaine de refonte du code. 1–2 semaines.
Nous découpons le système en modules, chacun avec son prix et son délai. Vous voyez ce qui entre dans le premier lancement et ce qui peut attendre. Livré avec le prototype.
Toutes les deux semaines — un module opérationnel que l'on peut ouvrir et essayer. Les priorités entre les étapes peuvent changer.
Nous migrons les données, formons l'équipe et gardons un œil pendant un mois. Ensuite — évolution selon vos besoins.
Une application web se chiffre non pas « à la page », mais selon la complexité de la logique. Les repères ci-dessous viennent de nos projets.
Un seul rôle utilisateur, une logique claire, quelques types de données.
Plusieurs rôles, vos propres processus, des rapports et des échanges avec l'existant.
Un service par abonnement : nombreux clients, offres, paiements, cloisonnement des données.
La première étape — analyse du processus et prototype — peut être commandée séparément pour $1200. Vous recevez un schéma du système et un chiffrage avec lesquels vous pouvez aller voir n'importe quel prestataire, pas seulement nous.
La question « sur mesure ou prêt à l'emploi » mérite une réponse honnête, et la réponse penche plus souvent vers le prêt à l'emploi. Si votre processus est classique et qu'il existe sur le marché un service qui le couvre pour un prix raisonnable, développer votre propre système sera plus cher et plus lent. Nous sommes les premiers à le dire à nos clients.
Un système sur mesure se justifie dans trois cas. Premier cas : le processus n'entre pas dans une logique étrangère — vous adaptez votre travail au logiciel au lieu que le logiciel s'adapte à vous. Deuxième cas : les fonctions nécessaires existent mais coûtent de façon disproportionnée — pour une seule fonctionnalité, il faut acheter l'offre la plus chère pour toute l'équipe. Troisième cas : le système est lui-même un produit que vous prévoyez de vendre.
Le principal risque de ces projets n'est pas technique : c'est de construire le mauvais système. C'est pourquoi nous ne commençons pas par le code, mais par l'analyse du processus actuel : qui fait quoi, d'où viennent les données, où exactement le temps se perd. Souvent, à cette étape, la moitié des souhaits initiaux disparaît — une solution plus simple suffit.
Vient ensuite un prototype cliquable sans design : un schéma des écrans, des transitions et des données. Modifier quelque chose dans le prototype coûte une heure ; dans du code écrit — des semaines. C'est ici que les erreurs de logique se détectent au moindre coût.
Le développement se fait par étapes, chacune avec son prix et son délai. Toutes les deux semaines, vous recevez une partie que l'on peut ouvrir et essayer. Cela lève la principale crainte des grands projets : à tout moment on voit ce qui a été payé, et à tout moment on peut s'arrêter avec un système opérationnel en main, et non un dossier de code.
Un espace client ou un calculateur avec un seul rôle — à partir de $6000 et 8–10 semaines. Un système interne avec plusieurs rôles, des processus et des rapports — à partir de $12000, à partir de trois mois. Un SaaS avec abonnements — à partir de $20000. Le chiffrage précis apparaît après le prototype.
Parce qu'avant l'analyse du processus, personne — ni nous ni vous — ne connaît le périmètre exact. On peut lancer un chiffre au hasard, mais il sera soit gonflé « par précaution », soit sous-évalué, et alors des travaux supplémentaires « apparaissent » en cours de route. Nous donnons une fourchette tout de suite, et le prix exact après le prototype, quand chaque écran est visible.
Souvent oui, et nous serons les premiers à le dire. Un système sur mesure se justifie quand votre processus n'entre pas dans une logique étrangère, quand les services prêts à l'emploi demandent un prix disproportionné pour les fonctions nécessaires, ou quand le système devient lui-même un produit.
Le prototype — 1–2 semaines après le démarrage, on peut déjà y cliquer. Le premier module opérationnel, qui s'ouvre dans le navigateur et fonctionne avec de vraies données — en 3–4 semaines. Ensuite, un nouveau module s'ajoute toutes les deux semaines.
Laravel côté back-end, Next.js ou Inertia + React côté front-end, PostgreSQL ou MySQL — selon le besoin. Applications mobiles — Flutter. Nous choisissons la pile en fonction du projet et de qui maintiendra le système ensuite.
Oui, c'est une étape standard du lancement. Nous migrons depuis des tableurs, des exports CSV ou directement depuis la base de l'ancien système. Avant la migration, nous montrons comment les données s'inscriront dans la nouvelle structure — pour ne pas découvrir après coup qu'il manque quelque chose.
Pendant un mois après le lancement, nous gardons un œil — c'est inclus dans le prix. Ensuite, soit un abonnement d'évolution, soit du travail à l'heure à la demande. Le code, le dépôt et les accès sont à vous : n'importe quel développeur peut poursuivre.
Discuter du système
Démarrer un projet