Une software house est une entreprise dont le cœur de métier est de construire et de maintenir des logiciels pour ses clients : custom development, modernisation de systèmes existants et le soin de longue durée qui les fait tourner. Choisir la bonne en Europe tient à cinq choses : des preuves vérifiables de travaux passés, des pratiques d’ingénierie plutôt que des promesses, un responsable clair de votre système après la livraison, une aisance réelle avec les règles européennes, et un modèle de prix qui correspond au degré de définition réel de votre projet.
Voilà la réponse courte. Le reste de ce guide détaille chaque point, du point de vue de gens qui s’assoient chaque semaine du côté fournisseur de ces conversations.
Ce qu’une software house fait, et ce qu’elle ne fait pas
Le terme couvre des entreprises de formes très différentes, donc la précision aide. Une software house construit du logiciel sur mesure : des systèmes conçus autour de vos processus, qui vous appartiennent, développés par une équipe qui fait cela pour de nombreux clients. C’est différent d’un éditeur (qui vous vend son logiciel), d’une agence digitale (dont le centre de gravité est le marketing), d’un body shop (qui vous loue des développeurs individuels en vous laissant le management de l’ingénierie) et d’un freelance (une personne, un facteur bus).
Aucune de ces alternatives n’est mauvaise. Elles sont mauvaises pour certains projets. Si ce qu’il vous faut est un système dont votre entreprise dépendra pendant des années, intégré à votre opération et maintenu à mesure qu’il évolue, vous cherchez du custom development auprès d’une software house, et les critères ci-dessous s’appliquent.
Pourquoi choisir en Europe est une question à part
La littérature mondiale de l’externalisation suppose généralement que le choix porte sur les taux horaires. Pour une entreprise européenne, trois autres facteurs sont devenus au moins aussi importants.
La réglementation est physique. RGPD, NIS2 et AI Act ne sont pas des abstractions ; ils déterminent où les données peuvent résider, comment les incidents doivent être signalés et comment les fonctions d’IA doivent être contrôlées. Une software house en Europe travaille sous les mêmes règles que vous, ce qui raccourcit chaque conversation de conformité. Nous avons écrit sur la couche plus profonde de ce sujet dans notre article sur la souveraineté numérique : votre partenaire technologique détermine votre exposition juridique autant que votre cloud.
La distance se mesure en heures ouvrées. Le chevauchement compte plus que la géographie. Un partenaire à un fuseau horaire rejoint votre cellule d’incident du mardi matin ; un partenaire à huit fuseaux répond pendant que vous dormez. Pour les systèmes qui portent votre opération, cette différence apparaît précisément les pires jours.
La relation survit au projet. Le logiciel sur mesure n’est pas terminé à la mise en production. Quelqu’un doit appliquer les mises à jour de sécurité, adapter le système quand votre activité change et en répondre quand quelque chose casse. Choisir une software house, c’est choisir qui est ce quelqu’un pour les cinq à dix prochaines années, un point que nous avons traité en profondeur dans notre guide sur l’externalisation de la maintenance.
Les cinq critères qui prédisent réellement un bon partenaire
1. Du travail vérifiable, pas des pages de portfolio
N’importe qui peut publier un portfolio. Demandez deux ou trois clients dont la situation ressemble à la vôtre, et parlez-leur. Les questions utiles ne sont pas « le projet était-il bon » mais « que s’est-il passé quand quelque chose a mal tourné » et « comment vit-on avec le système deux ans plus tard ». Une software house fière de son travail vous met en relation sans hésiter ; vous pouvez voir comment nous présentons le nôtre dans nos cas clients.
2. Une pratique d’ingénierie que vous pouvez inspecter
Demandez comment ils testent, comment ils relisent le code, comment ils déploient et quelle documentation un projet laisse derrière lui. Les réponses n’ont pas besoin d’être exotiques ; elles doivent être concrètes et routinières. Un partenaire incapable de décrire son propre processus en langage simple n’en suivra pas un sous la pression des délais. La documentation mérite une attention particulière : le test d’un bon custom development est de savoir si une autre équipe compétente pourrait reprendre le système à partir de ce qui est écrit.
3. Une réponse claire à « qui est responsable après la livraison »
La maintenance est l’endroit où le logiciel sur mesure réussit ou échoue financièrement. Avant de signer, vous voulez savoir : combien coûte le support, avec quels délais de réponse, et que deviennent ces conditions au fil des années ? Méfiez-vous des maisons qui traitent la maintenance comme une réflexion après coup ; construire puis s’en aller est le modèle économique qui produit les systèmes orphelins qu’on nous demande régulièrement de sauver.
4. Une aisance de conformité, pas du théâtre de conformité
Vous n’embauchez pas des juristes, mais votre software house devrait parler RGPD nativement : minimisation des données dans les conceptions, options d’hébergement UE, accords de traitement sans drame, et des réponses honnêtes sur ce que NIS2 ou l’AI Act signifient pour votre système précis. Les certificats, c’est bien ; des réponses précises à des questions précises, c’est mieux.
5. Un modèle de prix qui correspond à l’incertitude de votre projet
Le prix fixe fonctionne quand le périmètre est réellement fixe, ce qui est plus rare que tout le monde le prétend. La régie (time and materials) fonctionne quand le projet se découvre en chemin, et récompense un partenaire de confiance. Beaucoup d’engagements sains mélangent les deux : une première phase à périmètre fixe (un assessment ou une première version) qui permet aux deux parties de se mesurer, puis un arrangement plus long une fois que la confiance a des données derrière elle. Cette approche par étapes est exactement la raison pour laquelle nous proposons un technology assessment à périmètre fixe comme porte d’entrée.
Les questions qui valent la peine au premier rendez-vous
- Qui exactement travaillera sur notre projet, et quel est son niveau de séniorité ? (Les équipes montrées en réunion commerciale ont tendance à différer des équipes qui font le travail.)
- À quoi ressemble une semaine type de collaboration : réunions, démos, comptes rendus écrits ?
- Que se passe-t-il quand vous découvrez que le projet est plus gros qu’estimé ?
- Que possédons-nous à la fin : code, infrastructure, documentation, comptes ?
- Montrez-nous la documentation d’un projet passé (anonymisée, c’est très bien). Notre prochain fournisseur la comprendrait-il ?
- Quels systèmes maintenez-vous depuis plus de cinq ans ?
Les signaux d’alerte qui coûtent de l’argent plus tard, à coup sûr
- Un devis fixe détaillé produit en quelques jours pour un projet décrit vaguement. Une estimation sérieuse commence par des questions.
- Une réticence à inscrire au contrat les noms et les modalités de maintenance.
- Pas d’accès à des clients de référence, ou des références visiblement préparées pour vous.
- Du verrouillage par conception : frameworks propriétaires, licences sur votre propre système, hébergement qu’eux seuls peuvent toucher, documentation qui reste dans leurs têtes.
- Un prix dramatiquement inférieur à toutes les autres offres sérieuses. Le custom development a un plancher de coût réel ; en dessous, la différence sort de la qualité, de la séniorité ou du périmètre, et vous la paierez plus tard avec intérêts.
Local, nearshore ou lointain : un mot honnête sur les coûts
Les taux horaires diffèrent sensiblement à travers l’Europe et au-delà, et prétendre le contraire serait absurde. Mais le chiffre qui compte est le coût par système qui fonctionne, pas le coût par heure. Une équipe moins chère qui exige plus d’heures, plus de reprises et plus de temps de vos propres équipes pour la piloter n’est pas moins chère. Notre propre modèle combine une direction d’ingénierie belge avec des équipes en Europe et dans les Amériques, ce qui est une façon d’équilibrer taux, chevauchement et qualité ; d’autres équilibres sont légitimes. Ce qui compte, c’est que la software house sache expliquer où le travail se fait et qui en répond, au lieu de traiter cela comme un détail.
Où Dink se situe
Dink est une software house belge au service d’entreprises en Belgique, aux Pays-Bas et dans l’UE au sens large. Nous faisons du développement logiciel sur mesure, nous reprenons et maintenons des systèmes existants, y compris construits par d’autres fournisseurs, et nous intégrons l’IA là où elle mérite sa place. Nous publions notre façon de penser sur ce blog précisément parce que le critère numéro deux ci-dessus coupe dans les deux sens : vous devriez pouvoir inspecter comment une software house raisonne avant même de lui parler. Si ce guide correspond à ce que vous cherchez, notre page services montre comment les engagements sont structurés, et la conversation commence par un message.
Questions fréquentes
Qu’est-ce qu’une software house ?
Une software house est une entreprise spécialisée dans la construction et la maintenance de logiciels pour ses clients : custom development de nouveaux systèmes, modernisation de l’existant et maintenance de longue durée. Elle diffère d’un éditeur (vend son propre logiciel), d’une agence (centrée marketing), d’un body shop (loue des développeurs individuels) et d’un freelance (une seule personne).
En quoi une software house en Europe diffère-t-elle de l’externalisation offshore ?
Trois différences pratiques : elle opère sous les mêmes réglementations que vous (RGPD, NIS2, AI Act), elle travaille sur des heures qui se chevauchent, ce qui compte surtout pendant les incidents, et elle est joignable sous le même système juridique si la relation tourne mal. L’offshore peut rester pertinent pour du travail bien spécifié et à moindre risque ; les systèmes dont dépend votre opération gagnent à la proximité.
Combien coûte le custom development en Europe ?
Cela varie trop selon le pays, la séniorité et le type de projet pour un chiffre honnête unique. La comparaison utile est le coût par système qui fonctionne sur sa durée de vie, maintenance comprise, plutôt que le taux horaire. Obtenez plusieurs offres sérieuses sur le même périmètre écrit, demandez ce qui est exclu, et méfiez-vous de toute offre très en dessous des autres.
Prix fixe ou régie pour du logiciel sur mesure ?
Le prix fixe convient aux périmètres réellement fixes et bien spécifiés. La régie convient aux projets à forte part de découverte et exige de la confiance. Un modèle par étapes, avec une première phase à périmètre fixe suivie d’un engagement plus long une fois que les deux parties ont des preuves, capture l’essentiel des avantages des deux.
Que doit contenir le contrat avec une software house ?
La pleine propriété du code et des livrables, la documentation comme livrable explicite, des conditions de maintenance avec délais de réponse, des clauses de traitement des données pour le RGPD, la composition nominative de l’équipe, et une clause de sortie propre couvrant le transfert. Si un fournisseur résiste à la clause de sortie, vous avez votre réponse sur le verrouillage.
En train d’évaluer des partenaires pour un projet de custom development, ou héritier d’un système qui a besoin d’un nouveau foyer ? Commencez par un technology assessment à périmètre fixe, ou contactez-nous.