Choisir un prestataire de sous-traitance informatique sur la base de ses tarifs, de ses références ou des CV présentés ne suffit pas.
La qualité future de la collaboration dépend surtout de son organisation réelle : revue de code, tests, CI/CD, pilotage, stabilité de l’équipe, sécurité et transfert des connaissances.
Ces éléments sont souvent évoqués dans les présentations commerciales. Mais avant de signer, l’enjeu consiste à vérifier qu’ils sont réellement appliqués.
Voici les critères à analyser, les preuves à demander et les signaux qui doivent vous alerter.
Pourquoi la qualité est le vrai sujet de la sous-traitance informatique
Lorsqu’un projet externalisé rencontre des difficultés, c’est rarement uniquement la faute d’un développeur. Le problème vient souvent d’un système de delivery qui manque de garde-fous.
La qualité se dégrade lorsque :
- les exigences sont imprécises ou changent sans arbitrage ;
- le code n’est pas systématiquement revu ;
- les tests arrivent trop tard dans le projet ;
- les environnements sont instables ;
- les mises en production reposent sur des actions manuelles ;
- la connaissance est concentrée sur une ou deux personnes ;
- le pilotage ne s’appuie sur aucun indicateur fiable.
À l’inverse, la qualité se stabilise lorsque :
- les responsabilités sont clairement réparties ;
- une Definition of Done encadre chaque livraison ;
- les revues de code et les tests sont systématiques ;
- les déploiements sont automatisés et contrôlés ;
- les décisions, les risques et la documentation sont partagés ;
- la qualité est mesurée et pas seulement ressentie.
Le pays dans lequel se trouve l’équipe ne garantit donc pas la qualité. Madagascar, Maurice et le Vietnam peuvent constituer des destinations pertinentes, mais le résultat dépend avant tout des pratiques d’ingénierie, de l’encadrement et de la gouvernance du prestataire.
Les 7 critères pour choisir un prestataire de sous-traitance informatique
1. Des standards de qualité réellement appliqués
Un prestataire peut facilement affirmer qu’il accorde une grande importance à la qualité. Cette promesse ne vaut cependant rien sans processus concret.
Avant de vous engager, vérifiez :
- les conventions de développement utilisées ;
- les règles de revue de code ;
- les différents niveaux de tests prévus ;
- les critères permettant de considérer une fonctionnalité comme terminée ;
- la répartition des responsabilités entre les développeurs, le lead technique, le QA et le Product Owner.
Les preuves à demander :
- un exemple anonymisé de Definition of Done ;
- une checklist utilisée lors des revues de code ;
- un exemple de rapport de tests ;
- les règles appliquées avant la fusion d’une pull request.
Question à poser :
Qu’est-ce qui empêche techniquement la mise en production d’un code qui n’a pas été revu ou testé ?
Signal d’alerte :
La qualité dépend uniquement d’une vérification manuelle réalisée en fin de sprint ou avant la mise en production.
2. Une chaîne CI/CD capable de sécuriser les livraisons
Sans intégration et déploiement continus, les livraisons dépendent davantage d’interventions manuelles et sont donc plus exposées aux erreurs.
Un dispositif CI/CD structuré peut intégrer :
- la vérification du format et de la qualité du code ;
- l’exécution automatique des tests ;
- l’analyse des dépendances et des vulnérabilités ;
- la génération d’un build reproductible ;
- le déploiement sur un environnement de test ;
- une validation contrôlée avant la production ;
- une procédure de retour à la version précédente.
L’objectif n’est pas d’automatiser chaque action dès le premier jour. Il faut surtout que le prestataire soit capable d’expliquer son processus, ses contrôles et la manière dont il traite un échec de déploiement.
Les preuves à demander :
- un exemple anonymisé de pipeline ;
- la liste des contrôles exécutés automatiquement ;
- une présentation du processus de déploiement ;
- la procédure prévue en cas d’incident.
Question à poser :
Que se passe-t-il concrètement lorsqu’un test automatique échoue dans le pipeline ?
Signal d’alerte :
Les déploiements sont réalisés manuellement par une seule personne, sans procédure documentée ni solution de retour arrière.
3. Une équipe stable et correctement encadrée
Le turnover constitue l’un des principaux risques d’une collaboration externalisée. Le départ d’un développeur ne devrait pas provoquer une perte importante de connaissances ou bloquer les livraisons.
Évaluez notamment :
- le niveau de séniorité des profils proposés ;
- l’ancienneté moyenne des collaborateurs ;
- la présence d’un lead technique clairement identifié ;
- l’organisation du mentorat et des revues de code ;
- le partage des connaissances ;
- le dispositif de remplacement ou de renfort ;
- le nombre de projets sur lesquels les collaborateurs interviennent simultanément.
Les preuves à demander :
- la composition réelle de l’équipe ;
- les rôles et responsabilités de chacun ;
- le processus d’intégration d’un nouveau membre ;
- le plan de continuité prévu sur les compétences critiques.
Question à poser :
Comment assurez-vous la continuité du projet si un profil clé quitte l’équipe ou devient indisponible ?
Signal d’alerte :
Une équipe attractive sur le papier, mais reposant principalement sur des profils juniors ou sur un unique développeur senior.
4. Une gouvernance fondée sur des informations fiables
Un bon prestataire ne se contente pas d’exécuter les tickets qui lui sont transmis. Il doit également rendre visible l’avancement du projet, signaler les risques et faciliter les arbitrages.
Le dispositif de gouvernance peut comprendre :
- un point hebdomadaire sur les livraisons, les risques et les dépendances ;
- un comité de pilotage mensuel sur le budget, la qualité et l’équipe ;
- un backlog priorisé avec des critères d’acceptation ;
- un registre des risques et des actions associées ;
- une procédure claire pour gérer les changements de périmètre.
Les indicateurs doivent rester adaptés au projet. Accumuler les KPI ne sert à rien s’ils ne permettent pas de prendre une décision.
Parmi les mesures utiles :
- le délai entre le début d’un développement et sa mise en production ;
- la fréquence des déploiements ;
- le taux de bugs détectés après livraison ;
- le volume d’incidents en production ;
- le taux de retour arrière ;
- le temps moyen de rétablissement ;
- la stabilité de l’équipe.
Les preuves à demander :
- un exemple anonymisé de tableau de bord ;
- un compte rendu de comité de pilotage ;
- un exemple de registre des risques ;
- la liste des indicateurs réellement suivis.
Question à poser :
Comment rendez-vous visibles les retards, les risques techniques et les écarts de qualité ?
Signal d’alerte :
Les difficultés ne sont communiquées qu’au moment où elles affectent déjà les délais ou le budget.
5. Une réelle compréhension du produit et de ses enjeux
La qualité d’un projet ne dépend pas uniquement du code. Elle repose également sur la capacité de l’équipe à comprendre le besoin métier.
Un partenaire pertinent doit être capable de :
- questionner une demande imprécise ;
- proposer plusieurs options avec leurs compromis ;
- découper une fonctionnalité en étapes cohérentes ;
- identifier les dépendances et les zones de risque ;
- construire une roadmap réaliste ;
- alerter lorsqu’une décision augmente inutilement la complexité.
Les preuves à demander :
- un exemple de cadrage ou de spécification ;
- une décision technique argumentée ;
- un exemple de découpage fonctionnel ;
- la manière dont les développeurs accèdent au contexte produit.
Question à poser :
Pouvez-vous me donner un exemple de besoin client que vous avez remis en question et expliquer pourquoi ?
Signal d’alerte :
Le prestataire accepte toutes les demandes sans questionner leur utilité, leur faisabilité ou leurs conséquences techniques.
6. Des pratiques de sécurité intégrées au développement
La sécurité ne doit pas être traitée uniquement à la fin du projet.
Même en dehors d’un secteur fortement réglementé, plusieurs points doivent être vérifiés :
- gestion des accès selon le principe du moindre privilège ;
- protection et rotation des secrets ;
- séparation des environnements ;
- utilisation de données anonymisées pour les tests ;
- journalisation des actions sensibles ;
- contrôle des dépendances ;
- prise en compte des principales recommandations OWASP ;
- utilisation éventuelle d’outils SAST ou DAST selon les risques.
Les preuves à demander :
- la politique de gestion des accès ;
- le processus d’arrivée et de départ d’un collaborateur ;
- les règles de stockage des secrets ;
- un exemple de contrôle de sécurité intégré au pipeline.
Question à poser :
Comment les accès sont-ils retirés lorsqu’un collaborateur quitte le projet ?
Signal d’alerte :
Des comptes ou mots de passe sont partagés entre plusieurs personnes, ou des données de production sont utilisées librement dans les environnements de développement.
7. Un modèle de collaboration qui prévoit la réversibilité
Avant de signer, il faut déterminer comment la collaboration pourra évoluer, mais aussi comment elle pourra se terminer.
Le contrat et le fonctionnement opérationnel doivent préciser :
- la propriété du code et des livrables ;
- l’accès du client aux dépôts et aux outils ;
- les exigences de documentation ;
- le transfert régulier des connaissances ;
- les conditions de montée ou de réduction de l’équipe ;
- la procédure de sortie ;
- les modalités de restitution des accès, des données et des environnements.
La réversibilité constitue un bon indicateur de maturité. Un prestataire structuré ne construit pas une dépendance artificielle autour du projet.
Les preuves à demander :
- une clause de réversibilité ;
- un exemple de documentation technique ;
- une procédure de transfert des connaissances ;
- la confirmation que les dépôts de code restent accessibles au client.
Question à poser :
Si nous arrêtons la collaboration dans six mois, que nous remettez-vous et sous quel délai ?
Signal d’alerte :
Le prestataire conserve seul les accès, la documentation ou les connaissances nécessaires pour maintenir le produit.
La grille pour évaluer un prestataire avant de signer
Cette grille permet de comparer plusieurs prestataires sur des éléments vérifiables.
Attribuez une note de 0 à 2 à chaque critère :
- 0 : absent ou non démontré ;
- 1 : partiellement formalisé ;
- 2 : structuré, appliqué et démontré.
Axe évalué
0 point
1 point
2 points
Revue de code
Absente
Réalisée de manière informelle
Systématique, documentée et contrôlée
Stratégie de tests
Aucun processus défini
Tests partiels selon les projets
Niveaux de tests définis selon les risques
CI/CD
Livraisons manuelles
Automatisation partielle
Pipeline sécurisé avec contrôles et retour arrière
Gouvernance
Aucun suivi structuré
Rituels présents mais peu formalisés
Responsabilités, risques et KPI clairement suivis
Sécurité
Traitée ponctuellement
Quelques règles générales
Pratiques intégrées au développement et au CI/CD
Stabilité de l’équipe
Aucune visibilité
Continuité partiellement prévue
Lead, documentation et dispositif de remplacement
Compréhension produit
Exécution des demandes
Échanges fonctionnels ponctuels
Capacité démontrée à challenger et prioriser
Documentation
Absente ou tardive
Produite de manière irrégulière
Mise à jour au fil du projet
Réversibilité
Non prévue
Clause générale
Plan concret de transfert des accès et connaissances
Transparence
Informations communiquées tardivement
Reporting essentiellement déclaratif
Accès aux outils, métriques et risques partagés
Comment interpréter le résultat ?
- De 0 à 7 points : le risque est élevé. Le prestataire ne démontre pas suffisamment la solidité de son organisation.
- De 8 à 14 points : plusieurs bases existent, mais les zones faibles doivent être encadrées avant la signature.
- De 15 à 20 points : le dispositif paraît structuré. Il reste néanmoins nécessaire de le vérifier dans le cadre d’une mission pilote.
Cette note ne doit pas remplacer l’analyse humaine. Elle sert surtout à comparer les prestataires selon les mêmes critères et à éviter qu’une bonne présentation commerciale masque des faiblesses opérationnelles.
Comment tester la collaboration avant de s’engager sur la durée ?
Étape 1 : réaliser une évaluation initiale
Cette première étape permet de vérifier la maturité du prestataire à partir d’éléments concrets.
Elle peut inclure :
- l’analyse d’un dépôt de code existant ;
- l’étude des pratiques de test ;
- la revue du pipeline CI/CD ;
- l’évaluation du fonctionnement de l’équipe ;
- la définition d’une première gouvernance ;
- l’identification des principaux risques techniques.
L’objectif n’est pas de produire un audit excessivement long, mais de vérifier la cohérence entre le discours commercial et les pratiques réelles.
Étape 2 : lancer une mission pilote
Une mission pilote de quelques semaines permet d’évaluer la collaboration dans des conditions représentatives.
Le périmètre choisi doit être :
- limité ;
- suffisamment concret ;
- mesurable ;
- connecté au fonctionnement réel du produit ;
- livré avec les mêmes exigences que les futures fonctionnalités.
Pendant cette période, observez :
- la qualité des livrables ;
- le respect des engagements ;
- la capacité à signaler un problème ;
- la clarté des échanges ;
- l’autonomie de l’équipe ;
- la qualité de la documentation ;
- l’intégration avec vos équipes internes.
Une démonstration technique réussie ne suffit pas. Il faut également vérifier la capacité du prestataire à travailler avec votre organisation.
Étape 3 : organiser une montée en charge progressive
Si la mission pilote est concluante, la montée en charge peut être progressive :
- ajout de développeurs ;
- renforcement du lead technique ;
- intégration d’un profil QA ;
- amélioration du CI/CD ;
- formalisation des rituels et des indicateurs ;extension progressive du périmètre confié.
Cette progression réduit les risques et permet d’ajuster l’organisation avant de constituer une équipe plus importante.
Les signaux d’alerte à ne pas ignorer
Certains discours doivent immédiatement susciter des questions :
- « Les tests prennent trop de temps. »
- « Nous mettrons le CI/CD en place plus tard. »
- « Nous n’avons pas de lead, mais les développeurs sont autonomes. »
- « Nous livrons rapidement et nous corrigeons ensuite. »
- « La documentation n’est pas nécessaire. »
- « Nous ne suivons pas le turnover. »
- « Le client n’a pas besoin d’accéder directement au dépôt. »
- « Nous ne pouvons pas vous présenter l’équipe avant la signature. »
- « Nous n’avons pas d’exemple de reporting ou de processus à vous montrer. »
Un prestataire ne pourra pas nécessairement transmettre des documents provenant d’autres clients pour des raisons de confidentialité. Il doit cependant pouvoir présenter des modèles anonymisés, expliquer précisément ses pratiques et démontrer qu’elles ne sont pas uniquement théoriques.
Checklist avant de sélectionner votre partenaire IT
Qualité et ingénierie
- Definition of Done documentée ;
- revue de code systématique ;
- stratégie de tests adaptée aux risques ;
- pipeline CI/CD opérationnel ;
- procédure de mise en production et de retour arrière ;
- suivi des incidents et de la qualité après livraison.
Équipe
- profils réellement proposés identifiés ;
- lead technique et responsabilités définis ;
- ancienneté et stabilité de l’équipe connues ;
- plan de remplacement prévu ;
- organisation du transfert des connaissances ;
- disponibilité réelle des collaborateurs vérifiée.
Gouvernance
- rituels de suivi définis ;
- backlog et priorités accessibles ;
- indicateurs de qualité et de delivery partagés ;
- risques suivis avec des actions associées ;
- changements de périmètre encadrés ;
- responsabilités du client et du prestataire clarifiées.
Sécurité
- accès individuels et limités ;
- secrets protégés ;
- environnements séparés ;
- données de test maîtrisées ;
- dépendances contrôlées ;
- départ d’un collaborateur encadré.
Contrat et réversibilité
- propriété du code précisée ;
- accès au dépôt garanti ;
- documentation incluse dans les livrables ;
- propriété intellectuelle encadrée ;
- procédure de sortie définie ;
- transfert des connaissances prévu.
Conclusion : demandez des preuves, pas seulement des promesses
Choisir un prestataire de sous-traitance informatique ne revient pas à sélectionner une destination, un tarif ou une série de CV. Il s’agit de choisir un système de delivery capable de produire une qualité régulière dans la durée.
Les pratiques de QA, de CI/CD, de gouvernance et de documentation doivent pouvoir être expliquées, démontrées et vérifiées avant la signature.
Une mission pilote permet ensuite de confronter ces engagements à la réalité : qualité des livrables, transparence, capacité d’alerte, autonomie et intégration avec vos équipes.
Le bon partenaire n’est donc pas celui qui promet de ne jamais rencontrer de difficulté. C’est celui qui dispose d’un cadre suffisamment solide pour les détecter tôt, les rendre visibles et les traiter efficacement.
FAQ
Comment choisir un prestataire de sous-traitance informatique ?
Pour choisir un prestataire de sous-traitance informatique, évaluez ses pratiques de développement, la stabilité de son équipe, sa gouvernance, sa sécurité et ses conditions de réversibilité. Ne vous limitez pas aux tarifs et aux CV : demandez des preuves concrètes de ses processus, puis testez la collaboration sur une mission pilote avant d’élargir le périmètre.
Quels critères vérifier avant de sélectionner un prestataire informatique ?
Les principaux critères sont la revue de code, la stratégie de tests, le CI/CD, l’encadrement technique, le suivi des risques, la protection des accès et le transfert des connaissances. Le prestataire doit également être capable de comprendre vos enjeux métier, de challenger vos demandes et de rendre les difficultés visibles suffisamment tôt.
Quelles preuves demander à un prestataire informatique avant de signer ?
Demandez un exemple anonymisé de Definition of Done, une checklist de revue de code, un aperçu du pipeline CI/CD, un modèle de reporting et une procédure de réversibilité. Ces documents permettent de vérifier que les pratiques annoncées sont réellement structurées et ne reposent pas uniquement sur un discours commercial.
Comment vérifier la qualité d’un prestataire offshore ?
La meilleure méthode consiste à lancer une mission pilote sur un périmètre limité et représentatif. Évaluez la qualité du code, le respect des engagements, la capacité à signaler les risques, la documentation et l’intégration avec votre équipe interne. Le pays d’implantation ne garantit pas la qualité : celle-ci dépend surtout des compétences, de l’encadrement et des processus appliqués.
Comment éviter de devenir dépendant d’un prestataire informatique ?
Conservez l’accès aux dépôts de code, aux environnements et aux outils de pilotage. Exigez une documentation mise à jour, organisez régulièrement le transfert des connaissances et intégrez une clause de réversibilité au contrat. Celle-ci doit préciser les accès, les documents et les livrables qui vous seront remis à la fin de la collaboration.
