Choisir une ESN à Madagascar ne se résume pas à comparer des TJM ou à valider quelques CV. Dans la pratique, les écarts de performance viennent surtout de l’exécution : gouvernance, qualité, stabilité, sécurité, communication, et capacité à livrer de façon prévisible. Autrement dit, un bon partenaire n’est pas celui qui “promet”, mais celui qui a un système de delivery éprouvé.
Cet article propose 9 critères concrets pour distinguer un partenaire fiable d’un risque projet, avec des questions de due diligence et une grille simple pour décider.
Le premier signal d’une ESN fiable, c’est sa capacité à démarrer proprement. Un onboarding solide inclut :
la mise en place des accès (repo, CI/CD, environnements, outils)
la prise en main de l’architecture et des conventions
la cartographie des dépendances critiques (services, APIs, data)
une première priorisation du backlog avec des “quick wins”
À demander : “Quel est votre plan d’onboarding sur 2 semaines, jour par jour ?”
À vérifier : existence d’un template de “Kick-off pack” (checklists, RACI, conventions, rituels).
À distance, les zones grises coûtent cher. Un partenaire fiable propose une gouvernance simple :
Product Owner (responsable de la priorisation)
Tech Lead (responsable de la cohérence technique et de la qualité)
Delivery Lead / Scrum Master (responsable du flux et des rituels)
Sponsor côté client (responsable des arbitrages)
Rituels minimaux recommandés :
daily courte (15 min)
refinement hebdo
review de sprint avec démo
comité de pilotage hebdo (risques / arbitrages)
comité mensuel (budget, staffing, KPI, roadmap)
À demander : “Qui décide quoi, et à quelle fréquence ?”
Signal faible : “On s’adapte au fil de l’eau” sans structure formalisée.
La DoD (Definition of Done) protège la qualité et évite les livraisons “à moitié finies”. Une DoD corporate inclut en général :
PR (pull request) + revue de code
tests minimum (unitaires / intégration selon le contexte)
critères de sécurité basiques (secrets, dépendances)
mise à jour doc courte si nécessaire
monitoring/logs si livrable en prod
À demander : “Pouvez-vous partager votre DoD type ?”
Signal faible : “On verra plus tard les tests / la doc”.
Le code review est un accélérateur quand il est bien cadré : il réduit le rework, homogénéise le code, et diffuse les standards.
Bonnes pratiques attendues :
PR petites et fréquentes
checklist de revue (sécurité, perf, lisibilité, tests)
règles de merge (au moins 1 approbation, parfois 2)
conventions de nommage / architecture
À demander : “Combien de PR par semaine et quel délai moyen de revue ?”
À vérifier : existence de guidelines de code review + exemples anonymisés.
Une ESN fiable ne vend pas “100% de couverture”, elle vend une stratégie cohérente :
tests unitaires sur logique critique
tests d’intégration sur flux essentiels
un minimum d’end-to-end sur parcours métier (si produit)
gestion claire des bugs : triage, priorisation, SLA
À demander :
“Quelle est votre stratégie de tests par type d’application (API / front / mobile) ?”
“Quel est votre cycle de non-régression ?”
Signal fort : la qualité est intégrée au flux, pas ajoutée “en fin de sprint”.
Tu n’as pas besoin d’un programme sécurité lourd pour tout projet, mais tu as besoin d’une hygiène non négociable :
gestion des secrets (pas dans le code, rotation, coffre si possible)
gestion des accès (principe du moindre privilège)
scans basiques (dépendances, secrets, SAST selon contexte)
revue des endpoints sensibles, logs, données personnelles
À demander : “Comment gérez-vous les secrets et les accès ?”
Signal faible : accès partagés, secrets dans des fichiers, comptes non tracés.
La transparence, ce n’est pas envoyer des messages. C’est rendre le projet pilotable. Une ESN fiable suit quelques KPI simples :
lead time (idée → production)
fréquence de déploiement
taux de rework (bugs / retours QA)
incidents et MTTR (temps de résolution)
capacité / vélocité (avec prudence)
stabilité du staffing
À demander : “Quel tableau de bord fournissez-vous chaque semaine ?”
Signal faible : reporting uniquement narratif (“on a bien avancé”) sans métriques.
Les projets échouent souvent sur le facteur humain : turnover, absence de back-up, dépendance à une personne clé.
À sécuriser contractuellement et opérationnellement :
plan de continuité (remplacement sous X jours)
documentation minimale continue
pair programming ponctuel sur zones critiques
ownership partagé (pas de “single point of failure”)
À demander : “Quel est votre plan en cas de départ du Tech Lead ?”
Signal fort : l’ESN a un pool interne et un processus de handover.
Un partenaire fiable sait dire :
“ce scope est risqué”
“cette estimation est optimiste”
“ce choix technique va coûter cher à maintenir”
“voici 2 options avec leurs trade-offs”
Ce “challenge” doit être factuel, documenté, orienté solution.
À demander : “Donnez-moi un exemple où vous avez challengé un client et amélioré le résultat.”
Pour décider vite, note chaque critère sur 0–2 :
0 = non démontré
1 = partiel
2 = démontré + preuves (docs, templates, exemples)
Total /18 :
14–18 : partenaire structuré
10–13 : jouable avec cadrage renforcé
<10 : risque élevé
Si ton besoin est évolutif et la roadmap change souvent, la régie informatique à Madagascar peut être le bon modèle, à condition d’être cadrée par les éléments ci-dessus (KPI, DoD, gouvernance, sécurité).
En définitive, choisir une ESN à Madagascar doit reposer sur des preuves d’exécution : process, qualité, sécurité, pilotage par les indicateurs, et continuité. Ennov IT accompagne ses clients à structurer ce cadre dès le démarrage (onboarding, gouvernance, standards et KPI), afin de réduire le risque projet et d’installer une dynamique de livraison régulière, prévisible et orientée impact, au service de votre roadmap et de vos objectifs business.