MéthodeChoisir un prestatairePMEApplication métier
Faire développer une application sans équipe technique
6 min de lecture
Vous n'avez pas besoin d'une équipe technique pour faire développer une application métier. Votre rôle est de décrire le problème, de décider vite et de tester l'outil comme vos équipes l'utiliseront ; la conception, le développement, l'hébergement et la maintenance reviennent au prestataire. Un projet sans développeur interne réussit quand cette répartition est écrite dès le départ et qu'une personne, chez vous, a le pouvoir de trancher.
Cet article s'adresse aux dirigeants et responsables métier de PME qui n'ont ni DSI ni développeur. Il décrit ce que vous devez apporter, ce que le prestataire doit porter, et les six étapes d'un projet bien mené.
Ce que vous apportez, ce que le prestataire porte
Beaucoup de dirigeants pensent devoir « parler technique » pour piloter un projet logiciel. C'est l'inverse : votre valeur est dans la connaissance du métier, que le prestataire n'a pas. La technique est son travail.
| Sujet | Votre rôle | Le rôle du prestataire |
|---|---|---|
| Le besoin | Décrire le problème et ses règles | Le traduire en écrans et en fonctions |
| Les choix | Arbitrer entre les options proposées | Proposer des options chiffrées |
| La technique | Rien à décider | Choisir, justifier, documenter |
| La qualité | Tester avec de vrais cas | Tester le code, corriger, sécuriser |
| L'exploitation | Signaler les problèmes | Héberger, sauvegarder, maintenir |
Un bon prestataire vous pose des questions sur votre métier, pas sur des frameworks. S'il vous demande de choisir une base de données ou un hébergeur sans vous expliquer les conséquences, il vous transfère une décision qu'il devrait porter.
Les trois choses que personne ne peut faire à votre place
Décrire le problème réel. Pas la solution que vous imaginez, le problème que vous vivez : « nos techniciens ressaisissent chaque soir leurs fiches d'intervention », « nous ne savons jamais où en est une commande ». Apportez les documents existants (tableurs, formulaires papier, exports) : ils contiennent les règles métier plus sûrement qu'un entretien.
Décider. Un projet logiciel produit des dizaines de petites questions : ce champ est-il obligatoire, qui peut valider, que faire d'un doublon. Si chaque réponse attend une réunion de direction, le projet s'enlise. Nommez un référent qui connaît le terrain et peut dire oui ou non.
Tester. Personne d'autre que vos utilisateurs ne peut dire si l'outil fait vraiment le travail. Le prestataire teste que le code fonctionne ; vous testez qu'il sert à quelque chose.
Les six étapes d'un projet sans équipe technique
1. Formuler le problème en une page
Qui utilise l'outil, pour quelle tâche, à quelle fréquence, avec quelles données. Ajoutez ce qui coûte aujourd'hui (temps perdu, erreurs, informations introuvables) et ce qui doit absolument rester possible. Une page suffit pour un premier échange ; le reste se précise ensuite. Notre article sur le cahier des charges d'une application interne détaille ce qu'il faut y mettre.
2. Choisir le mode de réalisation et le prestataire
No-code, freelance, agence ou studio au forfait : chaque mode répond à une situation, et le comparatif agence, freelance ou no-code aide à trancher. Sans équipe technique, un critère pèse plus que les autres : qui assurera la maintenance dans trois ans, et ce qui se passe si cette personne n'est plus disponible. Pour interroger les candidats, utilisez nos 12 questions à poser à une agence.
3. Valider sur un prototype, pas sur un document
Un client non technique lit mal un cahier des charges de quarante pages, et c'est normal. En revanche, tout le monde sait dire « ce n'est pas comme ça que nous travaillons » devant un écran. Un prototype cliquable montre les parcours, les écrans et les données avant la moindre ligne de code de production. La différence entre prototype, maquette et MVP est expliquée dans cet article.
4. Fixer le périmètre et le prix
Le périmètre validé sur le prototype devient la base du devis. Au forfait, le prix est fixé sur ce périmètre ; tout ajout passe par un avenant chiffré avant d'être développé. C'est ce qui protège un client qui ne peut pas contrôler le nombre d'heures passées. Si plusieurs propositions sont sur la table, notre méthode pour comparer des devis de développement évite de comparer des périmètres différents.
5. Suivre le développement par paliers
Demandez des livraisons intermédiaires que vous pouvez utiliser, pas un rapport d'avancement en pourcentage. Un palier, c'est une partie de l'outil en état de marche, sur laquelle vos équipes peuvent déjà travailler. Un point court et régulier avec le prestataire suffit : ce qui a été livré, ce qui arrive, les questions en attente de réponse.
6. Recetter, mettre en service, puis exploiter
La recette est le moment où vous vérifiez que l'outil livré correspond à ce qui était convenu. Préparez des cas réels : une commande ordinaire, une commande avec une erreur, un client en double, la clôture de fin de mois. Après la mise en service, l'application doit être hébergée, sauvegardée, mise à jour et corrigée : ce travail continue, et notre article sur la maintenance d'une application métier explique ce qu'il recouvre.
Comment tester sans être technique
Une recette réussie ne demande aucune compétence en programmation. Elle demande de la méthode.
- Partez d'une journée réelle. Reprenez les tâches d'un utilisateur, dans l'ordre, avec de vraies données anonymisées si besoin.
- Testez les cas pénibles. Le cas simple marche presque toujours. Les problèmes viennent des exceptions : un client sans adresse, une commande annulée, deux personnes qui modifient la même fiche.
- Faites tester par ceux qui utiliseront l'outil. Le dirigeant voit les tableaux de bord ; l'opérateur voit les clics en trop.
- Notez précisément. Ce que vous avez fait, ce que vous attendiez, ce qui s'est passé, avec une capture d'écran. Un retour précis se corrige vite ; « ça ne marche pas » se corrige mal.
Les signaux d'alerte côté prestataire
Sans équipe technique, vous ne pouvez pas auditer le code. Vous pouvez en revanche repérer des comportements qui annoncent des difficultés.
- Il refuse de vous montrer quoi que ce soit avant la fin du projet.
- Il ne sait pas dire ce qui se passe si une fonction coûte plus cher que prévu.
- Il utilise une technologie rare ou maison, que peu d'équipes sauraient reprendre.
- Les comptes d'hébergement, le nom de domaine ou les données sont à son nom sans que le contrat dise comment vous les récupérez.
- Il répond à vos questions métier par du jargon au lieu de reformuler.
Le dernier point compte plus qu'il n'y paraît : si le prestataire ne sait pas expliquer simplement ses choix avant le projet, il ne saura pas vous alerter pendant.
Le temps à prévoir de votre côté
Faire développer une application ne demande pas un temps plein, mais pas zéro non plus. Le temps du client se concentre au cadrage, aux validations du prototype, aux points de suivi et à la recette. Les projets qui dérapent ont rarement manqué de développeurs ; ils ont souvent manqué d'un interlocuteur disponible côté client. Sur les délais en général, notre article combien de temps faut-il pour développer une application détaille ce qui allonge et ce qui raccourcit un projet.
Par où commencer
Écrivez votre problème en quelques lignes, sans chercher la solution, et désignez la personne qui tranchera. Chez LPR Studio, nous portons la conception, le développement, l'hébergement et la maintenance, et notre façon de travailler est pensée pour des clients sans équipe technique. La première étape est un prototype visuel gratuit, présenté en visio sous 5 jours ouvrés : vous jugez sur des écrans, pas sur un document.