Comment détecter le remplacement des seniors par des juniors dans un projet IT

Comment les prestataires remplacent les seniors par des juniors et comment le repérer

Sur un projet confié à un prestataire IT externe, la vitesse de développement a considérablement ralenti à plusieurs reprises — des tâches qui se bouclaient en deux jours s’éternisent désormais pendant des semaines. La raison n’est pas une dette technique ou des complications d’architecture, mais le fait qu’un tiers des développeurs seniors ont été discrètement remplacés par des juniors. Ce n’est pas un cas isolé : de tels remplacements deviennent une pratique systémique sur le marché de la CEI, surtout quand le client ne surveille pas la composition de l’équipe après le lancement.

Pourquoi ces substitutions passent-elles inaperçues

Le remplacement des niveaux de spécialistes ne se produit que rarement d’un seul coup. Les prestataires agissent progressivement : un senior est « muté sur un autre projet », remplacé par un « presque senior » avec un beau CV, puis un autre un mois plus tard. Le client voit la même structure d’équipe dans les rapports, les mêmes noms dans Jira, mais le niveau de compétence réel des exécutants diminue. Formellement — tout conforme au contrat, en réalité — de la tromperie.

Facteurs clés qui rendent ce schéma possible :

• Absence d’approbation obligatoire des remplacements par le client.
• Focus sur les métriques formelles (heures, tâches dans le sprint), pas sur la qualité du code et la profondeur des solutions.
• Implication insuffisante du responsable technique ou de l’architecte du client.

Les projets sont particulièrement vulnérables quand le client délègue toute la responsabilité technique au prestataire sans revues de code régulières ni audits. Si personne ne vérifie qui écrit le code et comment, le remplacement passe inaperçu jusqu’à une chute critique de la vélocité.

Comment repérer la substitution avant la crise

On peut détecter le problème bien avant qu’il n’impacte les délais. Voici les indicateurs clés :

• Ralentissement de la vélocité sans raisons objectives — si la complexité des tâches n’a pas augmenté et qu’aucune dette technique ne s’accumule, mais que les tâches se ferment plus lentement, c’est le premier signal.
• Augmentation des reprises et des bugs — les développeurs juniors commettent plus d’erreurs nécessitant des corrections. Si le pourcentage de bugs signalés par la QA ou en production grimpe — vérifiez qui les écrit.
• Baisse de la qualité du code — apparition d’anti-patterns, ignorance des standards, absence de tests là où ils étaient présents.
• Charge accrue sur les seniors restants — si les développeurs clés se mettent soudain à « aider » tout le monde, ils compensent probablement le faible niveau des nouveaux.
• Changement de ton dans la communication — les juniors posent moins de questions sur l’architecture, demandent plus souvent des instructions précises, évitent les tâches complexes.

Des revues de code régulières, du pair programming avec implication d’un représentant du client, et l’analyse de métriques (par ex. complexité cyclomatique, couverture, taux de churn) permettent de détecter le problème tôt.

Que faire : mesures préventives et réaction

Si vous avez affaire à un remplacement — pas de panique, reprenez le contrôle de manière systématique. Voici un plan d’action étape par étape :

• Réaliser un audit technique — pas sur les CV, mais sur le code réel et l’historique des commits. Qui a touché quels modules ? À quelle fréquence ? Quelle qualité ?
• Restaurer la transparence sur les remplacements — ajoutez une clause contractuelle obligeant le prestataire à faire approuver tout remplacement de spécialiste par le représentant technique du client.
• Remettre des seniors sur les rôles clés — si le budget le permet, remplacez les juniors par des middles/seniors. Sinon — redistribuez les tâches : laissez les juniors s’occuper de sections de code bien délimitées et documentées.
• Désigner une surveillance technique — même un seul architecte ou responsable technique du client effectuant des revues hebdomadaires réduit le risque de substitution de 80 %.
• Réviser les KPI d’équipe — au lieu de compter les heures pures et les tickets fermés, introduisez des métriques de qualité : bugs par commit, temps de reprise, couverture des changements.

Signaux d’alarme sur le marché

La situation est aggravée par certains prestataires qui utilisent consciemment ce schéma comme modèle économique : attirer le client avec une équipe de seniors aux tarifs du marché, puis les remplacer progressivement par des spécialistes moins chers, en gardant la marge. C’est particulièrement courant dans les régions à forte concurrence et sous pression sur les prix.

Deux règles strictes pour se protéger :

• Tarif inférieur à 25 $/heure pour un senior — signal d’alarme. Sur le marché de la CEI, un vrai senior ne travaille pas en dessous de ce seuil. Si l’offre semble trop belle — vérifiez le niveau via un test task ou du live-coding.
• Pas de tech lead ou PM du prestataire — risque. Une équipe sans leadership technique est plus sujette à la dégradation des compétences. Le tech lead est un filtre naturel contre les remplacements inqualifiés.

Points clés à retenir

• Remplacer des seniors par des juniors n’est pas une erreur, mais une stratégie délibérée de certains prestataires pour gonfler leurs marges.
• Premiers signes : ralentissement de la vélocité, augmentation des bugs, chute de la qualité du code — ils apparaissent bien avant la crise.
• Protection : approbations obligatoires des remplacements, revues de code régulières, tech lead côté client.
• Tarif du marché en dessous de 25 $/heure pour un senior en CEI — presque toujours une arnaque.
• La prévention vaut mieux que le remède : mieux vaut intégrer des contrôles dès le lancement que réparer le projet dans six mois.

Ne vous fiez pas aux rapports formels. Vérifiez qui écrit réellement votre code — aujourd’hui, pas il y a six mois. Votre projet dépend non pas de beaux CV, mais des vraies mains sur le clavier.

— Editorial Team