Aujourd’hui, la plupart des DSI se posent toujours la même question, à savoir « Faut-il internaliser les développements et la gestion du SI (Make) ou externaliser (Buy) ? ». Derrière ce choix se cachent des enjeux autrement plus complexes que la simple question du coût : dépendance technologique, gouvernance, stratégie d’entreprise…
Make or Buy : quels sont les enjeux pour les entreprises ?
Loin d’être une décision purement financière, ce dilemme touche au cœur de la stratégie IT.
Alors tout d’abord, qu’est-ce qui se cache derrière ces 2 concepts ? Quels sont leurs avantages respectifs et sur quels critères se baser pour faire le bon choix ?
Le “Make” (Internalisation)
- Contrôle total : Quand on développe ou gère en interne, on maîtrise le code, l’infrastructure, la roadmap, la cartographie. On ne dépend pas d’un prestataire qui peut changer ses priorités ou sa politique tarifaire.
- Protection des données : Si on héberge tout chez soi, on limite le risque de fuite ou de faille chez un tiers.
- Montée en compétence : Les équipes internes se forment, consolident un savoir-faire précieux.
Le “Buy” (Externalisation)
- Réduction des coûts : Du moins sur le papier. On n’a pas à recruter des devs ou admins en interne pour tout faire.
- Accès à une expertise spécialisée : Les prestataires sont experts dans leur domaine, et peuvent faire mieux / plus vite pour certaines technologies.
- Meilleure scalabilité : En externalisant, on peut ajuster les ressources selon la demande, sans se coltiner un parc serveur sous-utilisé ou des équipes surdimensionnées.
Les critères clés
- Coût total de possession (TCO) : Au-delà du prix initial, combien va coûter la maintenance, l’évolution, les upgrades ?
- Risques de dépendance : Si le prestataire ferme boutique, ou s’il impose un lock-in technologique, comment on s’en sort ?
- Capacité à recruter : si le marché manque de talents IT (et c’est actuellement le cas), vouloir tout faire en interne peut être suicidaire.
- Alignement avec la stratégie : L’IT est-elle un avantage concurrentiel que vous voulez maîtriser, ou un simple support ?
Les erreurs courantes dans une stratégie Make or Buy
Toutes les boîtes se sont plantées au moins une fois sur un projet en se fiant à des intuitions ou à des offres trop alléchantes. Voyons le top 3 des gaffes récurrentes.
1. Se baser uniquement sur le coût à court terme
L’externalisation semble souvent moins coûteuse à court terme, mais gare aux coûts cachés (clause d’évolution, support payant, etc.).
Solution : Évaluer le TCO sur plusieurs années, en intégrant maintenance, évolutivité, mises à jour, renégociations…
2. Sous-estimer les risques liés à l’externalisation
Dépendre d’un prestataire peut devenir piégeux : perte de contrôle, risques de lock-in, complexité des contrats, réversibilité compliquée…
Solution : Prévoir une gouvernance forte (SLA, clauses de réversibilité) et un plan B si le partenariat tourne au vinaigre.
3. Manque d’évaluation des compétences internes
Externaliser juste parce qu’on ne se sent pas à la hauteur peut faire perdre un savoir-faire critique. Vous êtes à la fois Directeur Marketing et en charge des relations avec votre partenaire IT (si si, dans les petites structures, ça arrive plus souvent que vous le croyez) ? Formez-vous.
Solution : Auditer en interne les compétences, mettre en place un plan de formation si on veut basculer vers le Make, ou au moins conserver un pool d’expertise pour interagir efficacement avec le prestataire.
La méthodologie en 5 étapes pour faire le bon choix
1. Analyse des besoins et des enjeux métier
On commence par la base. Quels sont les process IT vraiment stratégiques ? Quelles sont les exigences en termes de performance, de sécurité, d’évolutivité ? Si l’IT est au cœur de votre business model, le Make semble logique. Sinon, pourquoi pas le Buy.
2. Évaluation des coûts et des bénéfices
Comparez coûts directs, coûts indirects (licences, support, embauches, formation), bénéfices attendus (gain de productivité, rapidité time-to-market). Pensez « flexibilité et réactivité ». Monter une équipe IT performante est très compliqué. Mais opter pour prestataire low-cost qui met trois mois à répondre, n’est pas forcément un meilleur choix.
3. Analyse des risques
- Make : trouver et conserver les talents, risque d’obsolescence techno si on ne se met pas à jour, investissement initial potentiellement lourd…
- Buy : dépendre d’un fournisseur, risque de qualité de service inégale, renégociation du contrat, clauses douteuses…
4. Scoring et prise de décision
Préparez une matrice décisionnelle (coût, qualité, flexibilité, sécurité, etc.), attribuez un score par critère, et pondérez…
Pas très fun, mais ça évite de se fier à des impressions.
5. Plan de mise en œuvre
- Si Make : Prévoir un plan de montée en compétence, investir dans l’outillage, la culture devops, etc.
- Si Buy : Rechercher le bon prestataire (ou du moins une shortlist), cadrer le contrat (SLA, engagement de service, etc.), et ne pas oublier la clause de réversibilité si un jour on veut reprendre la main en interne.
Aussi pensez à vous faire accompagner dans votre réflexion. Un accompagnement expert pour sécuriser ses choix IT stratégiques est souvent bienvenu.
Bref, prenez le temps de poser les bonnes questions, de dialoguer avec la DSI (et pas seulement avec la direction financière), et vous éviterez bien des déboires. Parce qu’au final, qu’on opte pour Make ou pour Buy, l’important c’est surtout de garder la main sur la trajectoire IT et de s’assurer que ça serve le business plutôt que de le freiner. Et ça, croyez-moi, ça vaut largement quelques heures de réflexion en amont.