7 questions à poser avant de signer un logiciel

Un logiciel sur mesure mal choisi, c'est 6 à 18 mois de tension pour récupérer un outil qui ne fonctionne pas comme prévu, ou pire, pour recommencer avec quelqu'un d'autre. Ça arrive. Et dans la majorité des cas, les signaux étaient là avant la signature.

Voici les 7 questions qui séparent un bon prestataire d'un mauvais. Pas des questions pièges. Des questions auxquelles n'importe quel professionnel compétent doit pouvoir répondre sans hésiter.

1. "Qui va vraiment développer mon logiciel ?"

C'est la question fondamentale que personne ne pose. Quand vous signez avec une agence, qui développe concrètement : un développeur senior avec 10 ans d'expérience, un stagiaire supervisé, ou un sous-traitant à l'étranger dont vous ne connaissez pas le profil ?

La qualité du code dépend directement de qui le tape. Un junior bien encadré, ça peut être correct. Un senior qui gère 12 projets en parallèle, c'est risqué pour vous.

Ce que vous devez entendre : le nom et le profil du développeur affecté à votre projet, ses références sur des projets comparables, et sa disponibilité estimée pour votre mission. Demandez à le rencontrer en visioconférence avant de signer. Un bon prestataire n'a aucune raison de refuser.

2. "En combien de temps c'est livré ?"

En 2026, un logiciel simple se livre en 5 à 7 jours. Moyen, en 1 à 2 semaines. Complexe, en 2 à 4 semaines. Si quelqu'un vous annonce 3 mois pour un outil de gestion standard, c'est soit un projet d'une autre envergure, soit une équipe qui travaille à l'ancienne.

Exigez un planning écrit avec des jalons intermédiaires. Pas seulement une date de fin. Des étapes : brief validé, prototype présenté, fonctionnalités principales testées, version finale livrée. Un planning sans jalons n'engage personne.

3. "Que se passe-t-il si le résultat ne me convient pas ?"

Il faut d'abord définir "ne convient pas". Si le logiciel ne respecte pas les spécifications écrites et validées, c'est une erreur du prestataire. Les corrections doivent être gratuites. Si vous changez d'avis en cours de route et demandez des fonctionnalités supplémentaires, c'est un avenant qui se facture.

Ce que vous devez avoir par écrit : la durée de garantie sur les bugs (30 à 60 jours est standard), la distinction claire entre bug et changement de périmètre, et le processus de recettage, c'est-à-dire comment vous validez officiellement que le logiciel correspond à ce qui a été commandé.

4. "Qui est propriétaire du code ?"

Question juridique, mais cruciale. Il y a deux cas de figure principaux.

Vous êtes propriétaire exclusif du code source : vous pouvez le modifier vous-même, le confier à un autre prestataire, en faire ce que vous voulez. C'est l'option à privilégier pour tout logiciel qui devient stratégique pour votre activité.

Le prestataire garde la propriété et vous concède une licence d'usage : vous pouvez utiliser le logiciel, mais pas le modifier sans passer par lui. Moins cher à court terme, mais vous restez dépendant.

Pour 95% des PME, je recommande la propriété exclusive. C'est 10 à 15% plus cher, mais vous êtes propriétaire d'un actif numérique que vous contrôlez. Faites inscrire la clause de transfert de propriété dans le contrat, par écrit. Si le prestataire refuse de l'inclure, c'est un signal d'alerte.

5. "Comment fonctionne la maintenance après livraison ?"

Le logiciel est livré. Et après ? Il y aura des bugs mineurs, des mises à jour de sécurité, des petites évolutions à mesure que vous l'utilisez. Clarifiez ça avant de signer, parce que c'est là que les coûts cachés apparaissent.

Ce que vous devez savoir : la durée de garantie incluse (correction des bugs sans frais), le coût d'un plan de maintenance mensuel (200 à 300 euros par mois pour 5 à 7 heures de support est raisonnable), et si vous avez la possibilité de faire intervenir un autre prestataire en cas de besoin. Si vous êtes propriétaire du code, la réponse devrait être oui.

6. "Pouvez-vous m'aider pour les aides publiques ?"

Des aides régionales existent pour les projets numériques des TPE et PME, mais elles varient selon les territoires et évoluent d'une année à l'autre. Un prestataire qui accompagne régulièrement des PME doit connaître ces dispositifs et vérifier votre éligibilité avant de signer le devis, pas après (les dépenses déjà engagées ne sont généralement pas rétroactivement éligibles).

7. "Pouvez-vous me montrer un projet similaire ?"

La vérification finale. Demandez 2 ou 3 références dans votre secteur ou pour un type de besoin comparable. Demandez les coordonnées des clients concernés et appelez-en au moins un.

Les questions à poser à la référence : le projet a-t-il été livré à la date prévue ? Le prestataire a-t-il bien écouté les besoins ? Le logiciel fonctionne-t-il toujours comme prévu ? Ces trois questions vous disent tout.

Un prestataire sans références vérifiables n'a pas encore prouvé sa capacité à livrer. Ce n'est pas rédhibitoire si c'est compensé par d'autres garanties, mais ça doit être discuté ouvertement.

La checklist avant de signer

Avant de valider le contrat :

• •Vous connaissez le nom et le profil du développeur affecté
• •Vous avez un planning écrit avec des jalons de livraison
• •Les conditions de garantie et la distinction bug/changement sont écrites dans le contrat
• •La propriété du code source est définie par écrit
• •Le plan de maintenance post-livraison est chiffré
• •Le prestataire vérifie les aides publiques disponibles pour votre projet ou vous explique pourquoi ce n'est pas applicable
• •Vous avez appelé au moins une référence

Si le prestataire répond mal à l'une de ces questions, ne signez pas encore. Pas pour le piéger, mais parce que ces points résolus avant le démarrage évitent des conflits coûteux pendant le projet.

Vous cherchez un prestataire qui répond à toutes ces questions avant même que vous les posiez ? Réservez un appel de 15 minutes et nous vous montrons comment nous travaillons concrètement.