Le sur-mesure est rarement la première réponse
Développer une application coûte plus cher qu'un abonnement mensuel, et prend plus de temps qu'une installation. Alors quand un logiciel existant fait déjà 90 % du travail, je vous le dis, et on s'arrête là. Beaucoup de besoins qui arrivent chez moi sous le nom d'application se règlent en connectant deux outils que vous avez déjà.
Le sur-mesure devient la bonne réponse à partir du moment où votre métier a une particularité que personne n'a prévue, où vous payez plusieurs abonnements pour contourner l'absence d'une fonction, ou où vous tordez votre organisation pour entrer dans un outil. À ce stade, l'écart de coût s'inverse : ce que vous perdez chaque semaine finit par dépasser ce que coûterait l'outil juste.
Les projets qui reviennent le plus souvent
Six familles qui couvrent l'essentiel de ce que me demandent les PME. La vôtre en croise probablement deux.
Outils de gestion métier
Suivi de clients, de dossiers, de commandes ou de stock, avec vos étapes et votre vocabulaire. C'est ce qui remplace le tableur qui a grossi jusqu'à devenir dangereux à ouvrir.
Applications mobiles
iOS et Android à partir d'un seul code, publiées sur l'App Store et Google Play. Utile quand le travail se fait debout, sur le terrain, loin d'un bureau.
Portails clients
Un espace où vos clients suivent leur dossier, retrouvent leurs documents et déposent leurs demandes, sans passer par vous. Autant d'e-mails et d'appels en moins.
Réservation et planning
Prise de rendez-vous en ligne, gestion des disponibilités, confirmations et rappels automatiques. Là où un agenda partagé montre ses limites dès qu'on est plusieurs.
Applications de terrain
Pointage, rapports d'intervention, photos, signatures : saisis sur place depuis un téléphone, remontés directement au bureau. Fini la double saisie du soir.
Prototypes et premières versions
Vous avez une idée à valider avant d'y mettre un vrai budget. On construit une version réduite mais réellement utilisable, qu'on met entre les mains de vrais utilisateurs.
Trois outils livrés, et ce qui se passait avant
Les besoins n'ont rien à voir entre eux, et c'est justement le sujet : aucun logiciel du marché ne couvrait le cas de ces trois entreprises.
Un restaurant qui a repris la main sur son service
Réservations en ligne, plan de tables et menu du jour se pilotent depuis un tableau de bord unique, côté web comme sur mobile. Les réservations ne se notent plus au téléphone entre deux services, et la carte du jour est en ligne avant l'ouverture.
Une cave dont les stocks se tiennent à jour seuls
Chaque mois, il fallait ressortir les ventes des caisses et de la boutique en ligne, puis les reporter à la main dans le système comptable, sans jamais avoir de vue d'ensemble. Les œnothèques, le shop et la comptabilité sont maintenant synchronisés, les stocks se mettent à jour automatiquement, et les statistiques de ventes se sortent quand on en a besoin.
Une facturation qui a quitté Excel
Facturation autonome, relances et rappels clients envoyés sans y penser, liaisons fournisseurs, et surtout une vue des finances par projet et par client. C'est cette vue d'ensemble qui manquait le plus, et qu'aucun tableur ne donnait.
On réduit avant de construire
La façon la plus sûre de rater une application, c'est de vouloir tout couvrir dès la première version. On liste donc ce que vous imaginez, puis on coupe : ce qui reste, c'est ce sans quoi l'outil ne sert à rien. Le reste attend d'être réclamé par l'usage, et une bonne partie ne le sera jamais. Vous voyez tourner quelque chose vite, vous corrigez sur du concret plutôt que sur une maquette, et le budget part dans ce qui compte.
- 01
Regarder comment vous travaillez
Je vous observe faire, avec vos vrais dossiers. Ce qu'on décrit en réunion et ce qui se passe réellement le lundi matin sont deux choses différentes, et c'est la seconde qui compte.
- 02
Couper le périmètre
On sépare ce qui doit exister au premier jour de ce qui peut attendre. C'est la discussion la plus utile du projet, et souvent la plus inconfortable.
- 03
Livrer par morceaux utilisables
Vous recevez des versions à intervalles courts, que vous pouvez essayer pour de bon. Pas de tunnel de trois mois au bout duquel on découvre un malentendu.
- 04
Ouvrir aux équipes, puis ajuster
Mise en service, prise en main, puis un point après quelques semaines d'usage réel. C'est là qu'on voit ce qui manque vraiment, et ça ne figurait jamais dans la liste de départ.
Ce que je ne fais pas
- Vous vendre une application quand connecter vos outils existants suffirait
- Facturer des fonctionnalités que personne ne finira par utiliser
- Livrer un outil dont vous ne pouvez pas récupérer le code et les données
- Disparaître à la mise en ligne
Quand ça vaut le coup, et quand ça ne le vaut pas
On y va si
- Votre métier a une particularité qu'aucun logiciel du marché ne couvre.
- Vous payez plusieurs abonnements pour contourner l'absence d'une seule fonction.
- Un tableur partagé est devenu le cœur de votre activité, et ça vous inquiète.
- Vos clients vous appellent pour des informations qu'ils pourraient consulter seuls.
- Vos équipes de terrain ressaisissent le soir ce qu'elles ont déjà noté dans la journée.
On attend si
- Un logiciel existant fait déjà l'essentiel : on l'adapte plutôt que de repartir de zéro.
- Votre organisation change encore tous les mois : on figerait une cible mouvante.
- Le besoin se règle en connectant deux outils que vous avez déjà. C'est de l'automatisation, et c'est moins cher.
- Personne chez vous n'a le temps de suivre le projet : une application se construit à deux.
Une application qui recopie un fonctionnement bancal ne fait que le rendre plus difficile à changer. Quand c'est le cas, je préfère vous le dire avant de facturer.
Vos questions avant de vous lancer
Il n'y a pas de prix affiché sur cette page, et c'est volontaire : entre un outil interne pour trois personnes et une application mobile ouverte à vos clients, l'écart se compte en multiples, pas en pourcentages. Ce qui fait varier le budget, ce sont le nombre de fonctions au premier jour, le nombre de types d'utilisateurs, les outils à connecter, et la présence ou non d'une version mobile. Décrivez-moi votre cas et vous repartez avec un chiffre, pas une fourchette.
Une première version réellement utilisable sort en général entre quatre et six semaines. Une application complète, avec plusieurs types d'utilisateurs et des connexions à vos outils existants, demande plutôt deux à quatre mois. Vous ne découvrez pas le résultat à la fin : vous recevez des versions intermédiaires tout du long.
Non. Les deux plateformes sont développées à partir d'un seul code, ce qui évite de payer deux fois. Cela dit, je commence souvent par une application web accessible depuis un navigateur : elle couvre beaucoup de besoins et ne dépend pas d'une publication sur les stores. On ne passe au mobile natif que quand il apporte quelque chose de précis, comme le hors ligne ou les notifications.
Vous. Le code source et les données vous appartiennent, et vous pouvez les récupérer à tout moment pour les confier à quelqu'un d'autre. C'est une condition que je pose moi-même : un outil dont vous ne pouvez pas partir est un outil qui vous tient.
Ils changeront, c'est la règle plutôt que l'exception. L'application est construite pour qu'on puisse lui ajouter des choses sans tout reprendre, et le travail se fait par ajouts successifs plutôt que par grandes refontes. On regarde ce qui a bougé, on chiffre, vous décidez.
L'hébergement, les mises à jour de sécurité et la surveillance continuent après la livraison, sous forme d'un suivi mensuel adapté à la taille de l'outil. Une application laissée sans maintenance devient vulnérable en quelques mois, ce n'est pas une option de confort.
Oui, et c'est le choix par défaut dès qu'il y a des données de clients ou de collaborateurs. On retient un hébergement suisse ou européen selon leur sensibilité, et on documente ce qui transite où. C'est aussi ce qui vous permet de rester en règle avec la nLPD.
Oui, dans tout le Valais et en Suisse romande. Je suis basé à Martigny et je travaille régulièrement avec des PME de Sion, Sierre, Monthey, ou de stations comme Verbier et Crans-Montana. La phase d'observation gagne à se faire sur place, parce que c'est en vous regardant travailler qu'on comprend l'outil à construire. La suite se pilote très bien à distance.
Décrivez-moi ce que vous faites à la main chaque semaine.
On regarde ensemble si ça mérite une application, un simple branchement entre vos outils, ou rien du tout.
