Développer en interne, externaliser, ou acheter un logiciel du marché ?

« On veut une application sur mesure. » C’est souvent la première phrase du rendez-vous. Je demande alors pourquoi, et dans un cas sur trois environ, la bonne réponse était d’acheter un logiciel existant.

Ça peut paraître étrange de la part de quelqu’un qui vend du développement. Mais un projet sur mesure lancé alors qu’un progiciel aurait suffi finit mal, et je préfère le dire au premier rendez-vous qu’au dix-huitième mois.

La question à trancher en premier

Elle n’est pas technique. La voici : ce processus fait-il partie de ce qui vous différencie ?

Votre façon de faire la paie ne vous différencie pas. Votre comptabilité non plus. En revanche, votre façon d’organiser une tournée de livraison, de calculer un devis complexe ou de suivre un dossier client dans votre métier — c’est peut-être exactement ce qui fait que vos clients viennent chez vous et pas ailleurs.

Sur ce qui vous différencie, s’adapter à un logiciel standard revient à s’aligner sur vos concurrents. Sur tout le reste, se différencier ne rapporte rien.

Acheter un logiciel du marché

Quand c’est le bon choix : votre besoin ressemble à celui de milliers d’autres entreprises. Facturation, paie, CRM généraliste, gestion documentaire.

Le vrai coût, souvent oublié : l’abonnement par utilisateur qui grossit avec vos effectifs, les modules complémentaires, l’intégration avec vos autres outils, et surtout le coût de sortie si vous voulez changer plus tard.

Le piège : croire qu’un progiciel « à 90 % adapté » se complétera facilement. Les 10 % restants sont souvent précisément ce qui compte, et le paramétrage extrême d’un progiciel coûte régulièrement plus cher qu’un développement dédié — pour un résultat moins bon et non réversible.

Mon repère : si l’adaptation demande plus de trois développements spécifiques autour du progiciel, la comparaison mérite d’être refaite.

Photo : Helloquence — licence CC0.

Développer en interne

Quand c’est le bon choix : vous avez déjà une équipe technique, elle a de la capacité disponible, et l’application sera au cœur de votre activité pour les dix prochaines années.

Le vrai coût : ce n’est pas le développement, c’est la continuité. Une application interne dépend de personnes. Quand elles partent — et elles partent — l’application devient une boîte noire que plus personne n’ose toucher. J’ai vu ce scénario plus souvent que n’importe quel autre échec.

Le piège : démarrer avec un développeur motivé et sans processus. Ça fonctionne six mois, puis la personne change de poste.

Externaliser

Quand c’est le bon choix : vous avez besoin de la compétence maintenant, sans vouloir la recruter durablement — ou vous voulez la vitesse d’une équipe qui a déjà fait dix fois ce type de projet.

Le vrai coût : la dépendance, si vous n’avez pas négocié la réversibilité. Code, documentation, procédures : tout doit vous appartenir et être repris par un tiers en quelques semaines. Si ce n’est pas écrit, ce n’est pas vrai.

Le piège : externaliser aussi la connaissance métier. Le prestataire écrit le code ; la compréhension du besoin doit rester chez vous. Concrètement : quelqu’un chez vous doit pouvoir expliquer chaque règle de gestion de l’application.

Photo : rawpixel — licence CC0.

Photo : domaine public (CC0).

Le modèle qui marche le mieux, dans mon expérience

Un mélange, assumé dès le départ : un progiciel pour tout ce qui est standard, du sur-mesure pour ce qui vous différencie, et une intégration soignée entre les deux.

Les entreprises qui s’en sortent le mieux ne développent pas beaucoup. Elles développent peu, mais au bon endroit — et elles investissent dans les interfaces entre les briques, qui sont souvent le vrai chantier.

Le piège de la solution du marché personnalisée

C’est la voie médiane la plus séduisante et la plus coûteuse : acheter un progiciel, puis le faire adapter à vos processus.

Elle réunit souvent les inconvénients des deux options. Vous payez les licences, vous payez les développements spécifiques, et vous héritez d’une contrainte durable : chaque montée de version de l’éditeur oblige à vérifier, et parfois refaire, vos adaptations.

Au bout de quelques années, il n’est plus rare de voir des organisations bloquées sur une version ancienne parce que la migration coûterait plus cher que le projet initial — avec un éditeur qui finit par ne plus la supporter.

La règle que j’applique : un progiciel s’achète pour être utilisé tel quel, ou presque. Si le besoin d’adaptation dépasse le paramétrage prévu par l’éditeur, c’est le signal que le produit ne correspond pas au besoin. Mieux vaut alors changer de produit, ou adapter le processus, que transformer un achat en projet de développement déguisé.

La question du recrutement, quand on veut internaliser

Développer en interne suppose de recruter, et c’est là que les projets se heurtent au réel.

Un développeur seul dans une entreprise dont ce n’est pas le métier se retrouve sans personne pour relire son travail, sans progression technique et sans remplaçant. Le risque n’est pas sa compétence, c’est son isolement — et son départ, qui laisse une application que plus personne ne sait faire évoluer.

Le seuil réaliste pour une équipe interne autonome se situe autour de trois personnes, avec au moins un profil expérimenté. En dessous, le modèle mixte — une ou deux personnes en interne qui portent la connaissance métier, un partenaire externe pour la capacité et la relecture — est nettement plus robuste.

Trois questions avant de décider

1. Si nous n’avions rien fait pendant deux ans, qu’est-ce que ça coûterait ? Si la réponse est floue, le projet n’est pas mûr.
2. Ce processus, un concurrent pourrait-il l’acheter tel quel ? Si oui, achetez-le aussi.
3. Qui, chez nous, portera cette application dans trois ans ? S’il n’y a pas de réponse, le choix de la maintenance prime sur celui de la technologie.

Ces trois questions coûtent une réunion. Le mauvais choix coûte un budget annuel.