Faire développer une application : les questions à poser avant
Un développement sur mesure réussit ou échoue bien avant la première ligne de code. Les projets qui dérapent ont presque tous sauté les mêmes étapes au départ. Voici les questions que nous posons à nos clients — y compris celles qui nous desservent commercialement.
La première question : faut-il vraiment développer ?
C'est la question que peu de prestataires posent, et c'est pourtant la bonne. Un logiciel du marché coûte moins cher, se met à jour tout seul et ne dépend de personne. S'il couvre quatre-vingts pour cent de votre besoin et que les vingt pour cent restants sont des habitudes qu'on peut changer, le développement sur mesure est une erreur.
Le développement se justifie quand votre façon de travailler est précisément ce qui vous différencie, quand aucun logiciel ne couvre votre métier, ou quand il faut faire communiquer des outils existants qui s'ignorent. Nous commençons toujours par chercher s'il existe déjà une réponse. Quand elle existe, nous le disons.
Partir d'un problème chiffré, pas d'une liste de fonctions
Un cahier des charges qui énumère des écrans produit une application qui ressemble au cahier des charges. Un projet qui part d'un problème mesuré produit un outil qu'on utilise.
La bonne formulation ressemble à : « trois personnes passent chacune deux heures par jour à ressaisir des bons de livraison dans la comptabilité, avec des erreurs qu'on rattrape en fin de mois ». À partir de là, on sait quoi construire, dans quel ordre, et surtout comment savoir si c'est réussi. Un projet sans critère de réussite ne se termine jamais : il s'arrête quand le budget est épuisé.
Livrer petit et tôt, plutôt que grand et tard
Le risque principal d'un développement n'est pas technique, il est humain : construire pendant des mois quelque chose que personne n'utilisera. Il se maîtrise d'une seule façon, en livrant vite une version restreinte mais réelle.
Nous découpons donc le projet en étapes utilisables. La première version ne couvre qu'une partie du besoin, mais elle tourne, sur de vraies données, avec de vrais utilisateurs. Leurs retours réorientent la suite — et ils réorientent toujours quelque chose. Une application construite d'un bloc pendant six mois arrive avec six mois de malentendus accumulés.
Trois clauses à ne pas négliger
À qui appartient le code ? La réponse doit être écrite. Un client qui ne possède pas son code source est captif de son prestataire pour toujours, quelle que soit la qualité de la relation aujourd'hui.
Où tournent les données, et comment les récupérez-vous ? Un export dans un format standard doit être possible à tout moment, sans négociation.
Que se passe-t-il après la livraison ? C'est la clause la plus souvent absente, et la plus coûteuse. Une application sans maintenance casse — non par elle-même, mais parce que son environnement bouge : système, base de données, navigateur, service connecté. Le jour où ça casse, sans contrat, personne n'a le contexte ni les accès.
Pourquoi chaque développement se conclut par un contrat chez nous
Une part croissante de notre activité est le développement spécialisé sur demande : applications métier, connecteurs entre logiciels, automatisation de processus, interfaces avec des agents IA. Notre principe est constant : le développement se termine par la signature d'un contrat de maintenance.
Ce n'est pas une habitude commerciale, c'est la condition pour que l'outil vive. L'entreprise évolue, les règles changent, un utilisateur demande un champ supplémentaire, un partenaire modifie son format d'échange. Avec contrat, l'application accompagne votre activité. Sans contrat, elle devient une application orpheline six mois après la livraison — et nous en avons repris suffisamment pour savoir ce que cela coûte.
Ce que comprend notre prestation
- Cadrage : problème chiffré, critères de réussite, périmètre de la première version
- Développement par étapes livrables et testables
- Intégration avec vos logiciels existants et vos données réelles
- Reprise de l'existant et migration des données
- Code source et documentation remis au client
- Formation des utilisateurs et contrat de maintenance évolutive
Questions fréquentes
Cela dépend entièrement du périmètre, mais la bonne question est plutôt : au bout de combien de temps aurai-je quelque chose d'utilisable ? Nous visons une première version réellement exploitable rapidement, puis des livraisons régulières. Un projet dont la première livraison est annoncée dans six mois est un projet à risque.
Oui, et c'est écrit au contrat, avec la documentation technique. Vous devez pouvoir confier la suite à quelqu'un d'autre si vous le décidez. Un prestataire qui garde le code garde le client captif, et ce n'est pas notre façon de travailler.
C'est même souvent l'essentiel du travail. Comptabilité, gestion commerciale, paie, messagerie, site web : la valeur d'une application métier vient largement de ce qu'elle évite de ressaisir. Nous étudions les possibilités d'interfaçage de chaque logiciel concerné avant de nous engager.
Ils changeront — c'est la règle, pas l'exception. C'est exactement pourquoi nous livrons par étapes : chaque livraison est l'occasion d'ajuster la suite. Ce qui pose problème, ce n'est pas un besoin qui évolue, c'est un contrat rigide qui interdit d'en tenir compte.