Comment choisir une société de développement logiciel ?
Selon Mesterséges Intelligencia Központ Kft., société de développement logiciel basée à Budapest, un bon choix tient à trois questions : le développeur comprend-il l'objectif, son offre est-elle vérifiable, et à qui appartiendront le code et le système après la livraison ?
L'essentiel : décrivez d'abord l'objectif et les besoins indispensables, et ne demandez des offres qu'ensuite. Il est utile de demander à voir des réalisations qui fonctionnent, une méthode transparente et un accès au code ; les offres doivent être comparées sur la même spécification poste par poste, de préférence d'après une taille mesurée. Le contrat doit aussi fixer le code source et les droits d'utilisation, la confidentialité, la correction des anomalies, l'exploitation et les modalités de sortie.
D'abord l'objectif : que doit savoir faire le logiciel ?
La plupart des mauvais choix ne commencent pas chez le développeur, mais avec une commande floue. Si ce que le logiciel doit savoir faire n'est écrit nulle part, chaque offre signifiera autre chose, et il n'y aura rien à quoi comparer ni le prix ni le travail livré. Il n'est pas nécessaire d'avoir une spécification toute prête (un bon développeur aide à la rédiger), mais il vaut la peine de réfléchir à l'avance à quelques points :
- Objectif : quel problème le logiciel résout, et à quoi l'on verra qu'il est réussi.
- Utilisateurs : qui l'utilisera : des collaborateurs internes, des clients ou des partenaires.
- Besoins indispensables : ce sans quoi il ne peut pas être lancé, séparé des éléments « ce serait bien si ».
- Systèmes existants : à quoi il doit se connecter (ERP, CRM, boutique en ligne, logiciel de facturation, banque).
- Données : quelles données il traite, y compris des données personnelles.
- Cadre : s'il existe une échéance impérative, des règles internes, ou des exigences d'hébergement ou de sécurité.
Il vaut aussi la peine de décider s'il faut vraiment un développement sur mesure, ou si un produit prêt à l'emploi, voire un produit prêt à l'emploi complété par une extension sur mesure, suffit. L'article Logiciel sur mesure ou solution prête à l'emploi ? aide à trancher.
Liste restreinte : qui contacter ?
Inutile de contacter de nombreuses entreprises ; quelques candidats choisis avec soin valent mieux que de nombreuses offres superficielles. Les critères de sélection :
- Travaux similaires : a-t-il déjà construit un système de taille et de nature comparables (logiciel de gestion, boutique en ligne, application mobile, intégration d'IA) ?
- Adéquation technologique : travaille-t-il avec les technologies auxquelles les systèmes existants doivent se connecter ?
- Taille adaptée : la capacité de l'entreprise est-elle à la mesure du projet ? Un grand système demande plusieurs spécialités, une petite tâche moins.
- Langue et disponibilité : peut-il échanger avec vous dans votre langue et dans votre fuseau horaire ?
Vérifier les réalisations et les références
La preuve la plus solide est un logiciel qui fonctionne. Demandez aux candidats de montrer un système que l'on peut réellement essayer, et de dire précisément quelle a été leur propre part du travail. Beaucoup de travaux réalisés pour des clients sont protégés par la confidentialité ; on ne peut donc pas toujours citer de noms. Dans ce cas, une description anonymisée, une démonstration ou les propres produits de l'entreprise en disent aussi beaucoup.
Si un ancien client donne une référence, il est utile de poser des questions concrètes : le périmètre convenu a-t-il été respecté, comment les modifications et les anomalies ont-elles été traitées, le client a-t-il reçu le code source, et travaillent-ils encore ensemble ? Un « nous avons été satisfaits » général en dit peu ; le fait que le client exploite toujours le système avec eux après la livraison en dit beaucoup.
L'entretien technique
Il est utile de tenir un entretien technique avec chaque candidat, de préférence en présence d'un spécialiste technique de votre côté également. Ce qui compte, ce n'est pas l'assurance des réponses, mais le fait que le développeur pose des questions et nomme les risques. De bonnes questions :
- Comment vous y prendriez-vous, et quelle serait la première étape ?
- Comment connecteriez-vous nos systèmes existants, et que devez-vous savoir à leur sujet ?
- Comment testez-vous, et qui décide qu'une partie est terminée ?
- Qui travaillera sur le projet, et qui sera notre interlocuteur ?
- Où le système fonctionnera-t-il, et qui sera responsable des mises à jour de sécurité ?
- S'il comporte aussi de l'intelligence artificielle : quelles données vont où, et que se passe-t-il si l'IA se trompe ?
C'est un signal d'alerte si un candidat annonce un prix et un délai précis dès le premier entretien, sans poser de questions.
Processus et communication
En développement logiciel, les surprises naissent rarement dans le code, et bien plus souvent dans la communication. Il est donc utile de demander comment vous verrez l'avancement en cours de route. Les signes d'une bonne pratique :
- Développement par étapes : le travail est découpé en étapes, et à la fin de chacune, on vous présente un logiciel qui fonctionne, et pas seulement un compte rendu.
- Accès au code : le client voit le dépôt de code (repository) dès le premier jour, et ne le reçoit pas seulement à la livraison.
- Une liste de tâches traçable : les tâches, les anomalies et les modifications sont visibles dans un outil de suivi commun.
- Un interlocuteur permanent : une personne qui connaît le projet et peut prendre des décisions.
- Gestion des modifications : un besoin nouveau ou modifié est décrit, mesuré ou estimé, et n'entre dans le travail qu'après validation.
Comparer les offres
Deux offres ne sont comparables que si elles portent sur le même périmètre. C'est pourquoi chaque candidat doit recevoir la même description poste par poste ; demandez-leur pour quelles fonctions et pour quelle taille ils ont établi leur prix. Si le développeur mesure la taille fonctionnelle du logiciel avec une méthode normalisée, par exemple en points de fonction COSMIC, la taille peut être vérifiée à partir de la même spécification ; l'article Qu'est-ce qu'un point de fonction COSMIC ? présente la méthode.
Si l'écart entre deux offres est important, voici les questions à poser :
| Question | Ce qu'elle révèle |
|---|---|
| Pour quelle taille et quelles fonctions le prix est-il établi ? | s'ils ont chiffré le même périmètre |
| Qu'est-ce qui figure comme poste séparé ? | si l'intégration, la migration des données, les graphismes et l'exploitation sont inclus |
| Quelles exigences non fonctionnelles ont-ils prises en compte ? | performance, sécurité, accessibilité |
| Comment gèrent-ils les modifications ? | ce qui se passe si un nouveau besoin apparaît en cours de route |
| Quelles sont les modalités de correction des anomalies après la livraison ? | ce que couvre le prix, et ce qui compte comme travail supplémentaire |
| À qui appartiendra le code source, et quels droits obtiendrons-nous ? | si le système peut être repris par un autre prestataire |
| La facturation est-elle au forfait ou en régie ? | qui supporte le risque lié au périmètre |
Le prix forfaitaire fonctionne bien lorsque le périmètre est fixé poste par poste ; la facturation en régie est plus souple, mais le risque lié au périmètre reste à la charge du client. Dans les deux cas, ce qui compte, c'est que le périmètre soit mesurable et traçable. La page Tarification décrit comment nous fixons nos prix.
Les points essentiels du contrat
C'est le contrat qui compte en cas de litige ou de situation imprévue. Ce qui suit est donné à titre d'information et ne constitue pas un conseil juridique : il est utile de faire relire aussi le contrat par un juriste.
Code source et droits d'utilisation
La loi hongroise sur le droit d'auteur (loi LXXVI de 1999, Szjt., texte en hongrois) protège les programmes d'ordinateur, sous forme de code source comme de code objet, en tant qu'œuvres (article 1, paragraphe 2, point c)), et dispose que les droits patrimoniaux sur un logiciel sont cessibles (article 58, paragraphe 3). Le client acquiert donc soit les droits patrimoniaux, soit une autorisation d'utilisation (licence) ; les deux ne sont pas la même chose.
Quelques règles qui rendent une formulation précise importante : le contrat de licence ne confère un droit exclusif qu'en cas de stipulation expresse (article 43, paragraphe 1) ; si le contrat ne précise pas les modes et l'étendue de l'utilisation, l'autorisation est limitée à ce qui est indispensable pour atteindre l'objet du contrat (article 43, paragraphe 5) ; si le contenu est ambigu, l'interprétation la plus favorable à l'auteur prévaut (article 42, paragraphe 3) ; et le titulaire de la licence ne peut accorder une autorisation à un tiers qu'avec l'accord exprès de l'auteur (article 46, paragraphe 1). Il est donc utile de fixer :
- la remise de l'intégralité du code source et de la documentation, y compris étape par étape ;
- si le client acquiert les droits patrimoniaux, ou quelle licence il reçoit : exclusive ou non, modifiable ou non, transmissible ou non ;
- que le développeur détient les droits sur le code écrit par ses collaborateurs et par les prestataires externes auxquels il fait appel ;
- la liste et les licences des composants open source et tiers utilisés.
Confidentialité (NDA)
Si l'idée ou les données commerciales sont confidentielles, il est utile de conclure un accord de confidentialité (NDA) avant d'entrer dans les détails. Précisez-y ce qui constitue une information confidentielle, qui peut en prendre connaissance, combien de temps dure l'obligation de confidentialité, et ce qu'il advient des documents à la fin du travail.
Correction des anomalies et garantie
Le contrat doit préciser ce qui constitue une anomalie (un écart par rapport à l'exigence convenue), comment se déroule le test de réception, quels niveaux de gravité existent, et dans quel délai le développeur réagit pour chaque niveau. Précisez aussi pendant combien de temps il corrige gratuitement les défauts restés cachés lors de la livraison, et ce qui relève déjà d'une évolution.
Exploitation et SLA
Si le développeur exploite aussi le système après la livraison, un accord de niveau de service (service level agreement, SLA) en fixe les conditions : la disponibilité garantie, le mode de signalement des incidents, les délais de réaction et de résolution selon la gravité, les fenêtres de maintenance, les sauvegardes et les rapports. Ce qui n'est pas écrit ne peut pas être exigé en cas de litige.
Plan de sortie
Le plan de sortie répond à la question de savoir ce qui se passe si l'on ne poursuit pas avec le développeur, que ce soit par insatisfaction ou parce que le développeur cesse son activité. Ses éléments :
- une documentation à jour sur l'installation, l'architecture et l'exploitation ;
- le dépôt de code, l'hébergement, le nom de domaine et les comptes cloud au nom du client, ou au moins avec un accès pour le client ;
- les modalités de remise des mots de passe et des clés d'accès ;
- la possibilité d'exporter les données dans un format standard ;
- une coopération pour la transmission à un nouveau développeur.
Protection des données : le contrat de sous-traitance
Si le développeur a accès à des données personnelles au cours du travail (par exemple parce qu'il exploite le système ou effectue des tests avec des données de production), il est généralement qualifié de sous-traitant au sens du RGPD, et un contrat de sous-traitance écrit doit être conclu avec lui (RGPD, article 28). Ce contrat doit notamment prévoir que le développeur ne traite les données que sur instruction documentée du client, garantit la confidentialité et la sécurité, ne fait appel à un autre sous-traitant qu'avec autorisation, supprime ou renvoie les données au terme de la prestation, et permet la réalisation d'audits.
Pratiques de sécurité
La sécurité ne peut pas être ajoutée après coup à un logiciel ; il est donc utile de demander comment le développeur la prend en compte dans son travail. Un bon point de départ est l'OWASP Top 10, une liste largement connue des risques de sécurité les plus critiques pour les applications web ; l'édition en vigueur est l'OWASP Top 10:2025 (vérifié le 17 octobre 2026). Les trois premières places sont occupées par le contrôle d'accès défaillant, la mauvaise configuration de sécurité et les défaillances de la chaîne d'approvisionnement logicielle. Demandez :
- Comment gérez-vous les droits d'accès, et comment testez-vous qu'un utilisateur ne voit que ses propres données ?
- Comment mettez-vous à jour les bibliothèques externes utilisées, et comment savez-vous si l'une d'elles est vulnérable ?
- Où stockez-vous les mots de passe et les clés, et qui y a accès ?
- Y a-t-il une revue de code (code review) et des tests automatisés ?
- Comment les sauvegardes sont-elles réalisées, et avez-vous déjà essayé d'en restaurer une ?
Freelance ou société de développement ?
Les deux peuvent être un bon choix ; la question est de savoir quelle est l'ampleur de la tâche et quelle sera sa durée de vie.
| Critère | Freelance | Société de développement |
|---|---|---|
| Communication | directe, avec une seule personne | via un interlocuteur, avec plusieurs spécialistes |
| Domaines de compétence | les connaissances d'une seule personne | plusieurs domaines : interface, back-end, mobile, exploitation, tests |
| Remplaçabilité | en cas de maladie ou de départ, le travail s'arrête | l'équipe peut reprendre le travail des uns et des autres |
| Capacité | pour des tâches plus petites et bien délimitées | pour des systèmes plus grands et le travail en parallèle |
| Contrat | directement avec le spécialiste | avec l'entreprise, qui répond du travail de l'équipe |
| Exploitation à long terme | dépend de la disponibilité du freelance | peut être assurée de manière organisée |
Un freelance convient bien à une tâche bien délimitée, surtout si le client dispose de son propre responsable technique, qui pilote et réceptionne le travail. Si le système fait partie du fonctionnement quotidien de l'entreprise, exige plusieurs domaines de compétence et fonctionnera pendant des années, la société de développement représente généralement un risque moindre. Le plan de sortie et la remise du code source sont tout aussi importants dans les deux cas.
Signaux d'alerte
- Un prix et un délai précis dès le premier entretien, sans aucune question.
- Pas de spécification écrite, ou une offre qui ne dit pas sur quoi elle porte.
- Le client ne peut pas voir le code, et ne le recevrait qu'à la livraison.
- Une réponse floue sur qui travaillera sur le projet.
- On ne sait pas clairement à qui appartiendra le code source ni quels droits le client obtiendra.
- Un refus de signer un contrat de sous-traitance au sens du RGPD ou un accord de confidentialité.
- Aucune réalisation fonctionnelle à montrer.
Liste de contrôle
| Question | C'est bon si |
|---|---|
| L'objectif et les besoins indispensables sont-ils décrits ? | il existe une description courte, comprise de la même façon par tous |
| Avons-nous vu des réalisations qui fonctionnent ? | nous avons essayé au moins un système similaire |
| Comprennent-ils la tâche ? | ils ont posé des questions et nommé les risques |
| Verrons-nous l'avancement ? | démonstrations par étapes, accès au dépôt de code |
| L'offre est-elle comparable ? | elle porte sur le même périmètre poste par poste, et les postes séparés sont visibles |
| La question du code source et des droits est-elle réglée ? | le contrat mentionne la remise et l'étendue des droits |
| Y a-t-il un accord de confidentialité et un contrat de sous-traitance ? | signés là où c'est nécessaire |
| La correction des anomalies et l'exploitation sont-elles fixées ? | niveaux de gravité, délais de réaction, SLA |
| Y a-t-il un plan de sortie ? | documentation, accès, export des données |
| Avons-nous posé des questions sur la sécurité ? | des réponses concrètes sur les droits d'accès, les mises à jour et les sauvegardes |
Questions fréquentes
Freelance ou société de développement ?
Pour une tâche bien délimitée et de petite taille, un freelance expérimenté peut aussi être un bon choix, en particulier si l'entreprise a son propre responsable technique. Si le système fait partie du fonctionnement quotidien, exige plusieurs domaines de compétence et doit fonctionner longtemps, la société de développement représente un risque moindre, car le travail ne dépend pas d'une seule personne.
Comment comparer deux offres de prix ?
Seules des offres établies pour la même spécification poste par poste sont comparables. Demandez aux deux soumissionnaires pour quelle taille et quelles fonctions ils ont établi leur prix, ce qui figure comme poste séparé, et comment ils gèrent les modifications. Si la taille a été mesurée avec une méthode normalisée, par exemple en points de fonction COSMIC, elle peut être vérifiée à partir de la même spécification.
Que doit contenir le contrat ?
Le périmètre (la spécification poste par poste), le prix et le calendrier, la remise du code source et l'étendue des droits d'utilisation, la confidentialité, les modalités de réception et de correction des anomalies, l'exploitation et le SLA, le plan de sortie et, si des données personnelles sont concernées, le contrat de sous-traitance. Ces indications sont données à titre d'information et ne constituent pas un conseil juridique.
Que se passe-t-il si le développeur disparaît ?
Si le code source, la documentation et les accès sont entre les mains du client, un autre développeur peut reprendre le système. C'est pourquoi il est utile de voir le dépôt de code dès le premier jour, de garder l'hébergement et le nom de domaine à son propre nom, et de prévoir un plan de sortie dans le contrat. Sans cela, la reprise du système peut être difficile et lente.
À qui appartiendra le code source ?
À celui à qui le contrat l'attribue : selon la loi hongroise sur le droit d'auteur, les droits patrimoniaux sur un logiciel sont cessibles, mais cela n'a rien d'automatique. Il est utile de prévoir dans le contrat que le client reçoit l'intégralité du code source, et quels droits précis il acquiert sur celui-ci. Chez nous aussi, le code source et les droits d'utilisation sont régis par le contrat.
Comment pouvons-nous vous aider ?
Voici notre façon de travailler : le premier échange est gratuit, nous rédigeons la spécification ensemble, nous mesurons la taille du logiciel en points de fonction COSMIC, et l'offre et le calendrier en découlent. Le développement avance par étapes, avec une démonstration à la fin de chacune ; sur demande nous signons un accord de confidentialité (NDA), et après la livraison nous assurons aussi l'exploitation et la maintenance. Le code source et les droits d'utilisation sont régis par le contrat. Les étapes sont décrites sur la page Notre méthode de travail, et la méthode de tarification sur la page Tarification.
Nous développons actuellement un grand système ERP et CRM ; nous présentons nos propres développements, que l'on peut essayer, sur la page Nos réalisations, vous trouverez des informations sur l'entreprise sur la page À propos, et les réponses aux questions courantes sur la page Questions fréquentes. Si vous cherchez un développeur, écrivez-nous via les coordonnées indiquées sur la page Contact.