7 questions à poser avant de signer un logiciel

Vous avez identifié un prestataire pour votre logiciel sur mesure. Avant de signer, vous vous posez mille questions — c'est normal. Un logiciel, c'est un investissement important. Et contrairement à acheter un logiciel standard, il n'y a pas de garantie de retour simple. Les bonnes questions avant de signer logiciel sont essentielles.

Voici les 7 questions que vous devez absolument poser avant de signer votre logiciel et de donner le feu vert. Ce ne sont pas des questions pièges. C'est juste ce qui sépare une bonne prestation d'un cauchemar administratif.

Consultez aussi notre guide sur Bpifrance pour approfondir le sujet. Explorez aussi France Num, les-aides.fr, et votre CCI locale pour toutes les subventions possibles.

Question 1 : "Qui va vraiment développer mon logiciel ?"

C'est la question fondamentale. Quand vous signez avec une agence, qui développe : un développeur senior avec 10 ans d'expérience, ou un stagiaire ? Un développeur basé en France ou sous-traité en Inde ? Une seule personne ou une équipe ?

Pourquoi c'est important : parce que la qualité du code dépend directement de qui le tape. Un junior avec de la bonne supervision, c'est correct. Un senior solo sur 10 projets à la fois, c'est problématique.

Ce que vous devez entendre :

• •"Vous travailler avec [Nom du dev], qui a [X années] d'expérience en [votre métier]"
• •"Voici ses projets précédents [liens ou références]"
• •"Il sera disponible 80% du temps sur votre projet [durée précise]"

Ce qu'il NE FAUT PAS entendre :

• •"L'équipe fera le projet" (trop vague)
• •"On verra selon les charges" (c'est votre projet qui attend)
• •Aucune référence concrète

Faites-vous présenter la personne (appel visio). Demandez ses références précédentes. Un bon dev n'a rien à cacher.

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

Vous savez déjà que les délais en 2026 sont rapides. Un logiciel simple : 5-7 jours. Moyen : 1-2 semaines. Complexe : 2-4 semaines.

Si quelqu'un vous dit "3 mois", c'est soit un gros projet, soit une équipe inefficace.

Ce que vous devez entendre :

• •Un planning détaillé : J1-J2 (brief), J3-J5 (prototype), J6-J8 (intégration), J9-J10 (tests)
• •Des jalons de livraison intermédiaires (pas juste "tout d'un coup")
• •Une date de fin précise, par écrit

Ce qu'il NE FAUT PAS entendre :

• •"Ça dépend, on verra" (irresponsable)
• •"3-4 mois standard" pour un projet simple (inefficace)
• •Aucune date arrêtée par écrit

Exigez un planning écrit avant de signer, même approximatif. Ça engage le prestataire.

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

Première étape : bien définir "convient pas".

Si le logiciel livre ne respecte pas les spécifications convenues (par écrit), c'est la faute du dev. Il faut corriger, gratuitement.

Si vous changez d'avis ("finalement on veut 3 écrans de plus"), c'est un changement de scope. Ça coûte un supplément.

Ce que vous devez entendre :

• •"Les corrections de bugs sont gratuites pendant [30-60 jours]"
• •"Les changements de spécifications se paient en sus"
• •Un processus de recettage clair (vous, on teste ensemble, vous signez quand c'est bon)
• •Une clause de limitation de garantie (5-10% du prix)

Ce qu'il NE FAUT PAS entendre :

• •"Remboursement complet si ça ne vous plaît pas" (irréaliste)
• •"C'est vous qui spécifiez mal" (mauvaise attitude)
• •Rien du tout sur le sujet (danger)

Faites valider par écrit la différence bug/changement avant de signer. C'est l'une des plus grandes sources de conflits.

Question 4 : "Qui est propriétaire du code ?"

C'est juridique, mais crucial. Quand vous payez un logiciel, à qui appartient vraiment le code source ?

Il y a 3 cas :

Cas 1 : Vous êtes propriétaire du code (ce qu'on appelle "propriété exclusive")

• •Vous pouvez faire ce que vous voulez du code (le modifier, le revendre, le donner)
• •Plus cher, mais c'est l'option à privilégier pour un logiciel mission-critique

Cas 2 : Le prestataire garde la propriété, vous avez une licence d'usage

• •Vous pouvez utiliser le logiciel, mais pas le modifier vous-même
• •Moins cher, mais vous dépendez du prestataire pour la maintenance

Cas 3 : Propriété partagée (rare, à éviter)

• •C'est flou, ça crée des conflits

Ce que vous devez entendre :

• •Soit : "Vous serez propriétaire du code source complet"
• •Soit : "Vous aurez une licence perpétuelle d'usage, non-exclusive" (avec détails)

Ce qu'il NE FAUT PAS entendre :

• •"On verra" (trop vague)
• •"C'est standard dans notre contrat" sans l'expliquer

Pour 95% des PME, je recommande : propriété exclusive du code. C'est 10-15% plus cher, mais c'est votre actif numérique. Vous n'êtes pas coincé.

Exigez une clause écrite de transfert de propriété dans le contrat. Pas de contrat, pas de signature.

Question 5 : "Comment fonctionne la maintenance après livraison ?"

Après livraison, le logiciel aura besoin de maintenance : petites corrections, mises à jour de sécurité, améliorations.

Vous DEVEZ clarifier ça avant de signer, parce que c'est une source régulière de coûts.

Ce que vous devez entendre :

• •"Les 3 premiers mois, on corrige les bugs gratuitement"
• •"Après, vous pouvez passer sur un plan de maintenance"
• •"Il y aura une formation pour que vous compreniez les bases"
• •"Vous pouvez même faire modifier le code par quelqu'un d'autre si vous voulez (puisque vous le possédez)"

Ce qu'il NE FAUT PAS entendre :

• •"On ne s'en occupe plus après livraison" (mauvais service)
• •"C'est 50% du prix initial par an, obligatoire" (piégeux)
• •Rien du tout sur le sujet (indifférent)

Négociez un plan de maintenance forfaitaire (ex : 200€/mois pour 5h de support tech). C'est plus sain qu'une facturation à l'heure.

Question 6 : "Pouvez-vous m'aider pour les subventions ?"

Voici un secret : 80% des logiciels sur mesure peuvent être financés partiellement par des subventions publiques (France Num, Bpifrance, aides régionales).

Un bon prestataire doit pouvoir vous aider sur ça.

Ce que vous devez entendre :

• •"Oui, on aide nos clients à monter les dossiers de subvention"
• •"Voici comment ça marche" (explication claire)
• •"Vous pouvez récupérer [20-70]% de la facture via une subvention"
• •[Ou même : "On s'en occupe, vous avez juste à signer"]

Ce qu'il NE FAUT PAS entendre :

• •"On n'en parle jamais" (mauvais service)
• •"C'est votre problème" (vous laissez de l'argent sur la table)

Chez HIC, par exemple, on aide nos clients à accéder aux subventions pour la formation IA et France Num. Ça diminue votre facture réelle de 30-50% en moyenne.

Exigez une aide explicite sur ce sujet. Sinon, vous laissez 5K€ sur la table.

Question 7 : "Je peux voir un projet similaire que vous avez réalisé ?"

C'est la vérification finale. Demandez des références concrètes.

Ce que vous devez entendre :

• •"Voici 2-3 projets qu'on a faits dans votre secteur"
• •"Voici les contacts des clients (ils peuvent parler en votre faveur)"
• •"Voici les chiffres : combien ça a coûté, combien de temps ça a pris"

Ce qu'il NE FAUT PAS entendre :

• •"On peut rien montrer, confidentialité" (acceptable, mais alors ils doivent expliquer avec des mots)
• •"On n'a jamais fait de logiciel pour votre métier" (attention danger)
• •Aucune référence du tout (FUITE)

Appelez une de ces références. Posez des questions simples :

• •"C'était livré à la date prévue ?"
• •"Le prestataire a écouté vos besoins ?"
• •"Vous l'avez recommandé ?"

Une bonne agence aura 3-5 clients satisfaits qui parleront en sa faveur.

Résumé : les 7 checklist avant de signer

Avant de cliquer sur "valider le contrat", vérifiez :

• • Q1 : Vous connaissez le nom, le profil et l'expérience du dev
• • Q2 : Planning écrit avec jalons de livraison
• • Q3 : Clauses claires sur les corrections et les changements de scope
• • Q4 : Propriété du code définie par écrit (de préférence propriété exclusive)
• • Q5 : Plan de maintenance post-livraison défini
• • Q6 : Aide explicite pour les subventions (ou explication pourquoi c'est pas possible)
• • Q7 : Au moins 2 références que vous pouvez appeler

Si le prestataire répond mal à l'une de ces questions, ne signez pas. C'est un signal d'alerte.

Et si vous vous demandez quels éléments doivent être inclus dans le devis avant de signer, relisez notre guide sur le cahier des charges — c'est la fondation de tout contrat qui fonctionne bien.

Et si vous ne savez pas par où commencer...

Il est facile de vous sentir perdu face à tous ces critères. C'est pour ça que nous proposons un diagnostic express gratuit : un appel de 15 minutes où nous répondons à vos vraies questions et vous aidons à clarifier vos besoins avant même de parler devis.

Vous pouvez aussi consulter notre offre logiciel sur mesure pour voir comment d'autres entreprises de votre taille ont procédé — avec les vraies questions qu'elles se posaient.

Envie de discuter de votre projet ? Prenez rendez-vous avec un expert HIC — c'est gratuit, zéro engagement.