Répartition des rôles DSI prestataire sur un projet avec dette technique

Pour sécuriser un grand projet logiciel posé sur un existant chargé en dette technique, votre sujet central est la répartition précise des rôles entre DSI et prestataire : qui décide, qui exécute, qui assume quel risque, à quel moment. Se limiter au choix régie/forfait ou centre de services ne suffit pas, surtout quand l’architecture, la dette accumulée, l’intégration au SI et la mise en production sont imbriquées.

Vous devez composer avec un SI hétérogène, des contraintes métier fortes, des équipes internes déjà chargées et, parfois, une couche IA qui ajoute des enjeux de données et de souveraineté. L’enjeu n’est pas seulement de « faire le projet », mais de cadrer contractuellement les zones grises pour éviter les transferts implicites de risque et les dépendances subies.

Cet article fait partie du dossier Pilotage projet SI : croiser dette technique et produit.

Cartographier les zones de risque d’un projet avec dette technique

Pour répartir les rôles avec un prestataire, vous devez d’abord savoir précisément où se situent vos risques techniques et opérationnels. L’objectif n’est pas un inventaire complet du SI, mais une carte utilisable en comité de pilotage pour dire qui porte quoi, sur quelle brique et à quel moment.

1. Repérer les trois couches critiques de dette technique

• Base de données : schémas vieillissants, procédures stockées opaques, absence de tests sur les migrations. Résultat attendu : une liste des tables et procédures « intouchables » sans plan de régression.
• Couches d’intégration : ESB, flux batch, APIs, scripts. Résultat attendu : un inventaire des flux qui, s’ils tombent, bloquent une activité métier ou une facturation.
• Interfaces métier historiques : écrans clients lourds, macros, formulaires critiques. Résultat attendu : une cartographie des écrans ou parcours où le moindre ralentissement crée une file d’attente ou une perte de productivité.

2. Identifier les dépendances invisibles pour un prestataire

• Listes de codes métiers non documentés, règles « dans les têtes », scripts locaux chez certains utilisateurs.
• Résultat attendu : un tableau « dépendance / propriétaire / impact si modifié » que vous pouvez opposer à tout planning irréaliste.

3. Qualifier les risques liés aux environnements d’intégration et de production

• Intégration continue : données de test proches du réel, jeux de données pour IA, temps moyen pour rejouer une campagne de tests.
• Production : fenêtres de déploiement acceptables, capacité de rollback, contraintes de continuité d’activité pour les systèmes legacy.
• Résultat attendu : pour chaque environnement, un périmètre sur lequel vous exigez une validation conjointe DSI–prestataire.

4. Cartographier les risques humains et disponibilité des experts

• Experts métier clefs, sachants techniques sur les systèmes anciens, administrateurs de données pour les projets IA.
• Résultat attendu : un planning de disponibilité réaliste de ces profils, intégré comme contrainte dans l’organisation projet.

5. Positionner chaque risque sur le cycle de vie du projet

• Pour chaque zone (données, intégration, interfaces, environnements, humain), indiquer : risque en cadrage, en build, en bascule, en run.
• Résultat attendu : une matrice simple « zone de risque × phase » qui servira de base pour répartir responsabilités, décisions et engagements contractuels avec le prestataire.

Choisir un scénario d’organisation adapté à son existant

Pour sécuriser un grand projet logiciel ou IA sur un SI chargé en dette technique, votre choix d’organisation doit partir de trois paramètres : niveau de dette, disponibilité des équipes internes et contraintes de continuité d’activité. Les trois scénarios ci-dessous ne sont pas exclusifs : vous pouvez les combiner selon les phases du projet.

Scénario	Quand l’utiliser	Rôles internes dominants	Rôles prestataire dominants	Avantages	Points de vigilance
Pilotage interne fort	Dette technique élevée, forte dépendance au legacy, contraintes de continuité d’activité critiques.	Architecture cible, arbitrages de dette technique, priorisation du backlog, validation des choix d’intégration et de sécurité.	Analyse et chiffrage, développement, tests d’intégration sous référentiel défini par vos équipes.	Maîtrise des risques SI, réduction de la dépendance, alignement étroit avec les contraintes de production.	Charge forte sur vos experts, risque de goulots d’étranglement si la disponibilité métier et technique est limitée.
Modèle mixte	Dette technique moyenne à forte, ressources internes contraintes, besoin de montée en charge rapide.	Co-pilotage de l’architecture, validation des patterns d’intégration, ownership des environnements d’intégration et de production.	Lead sur le delivery (build, tests, automatisation), contribution à la dette technique « opportuniste » (corrigée au fil de l’eau).	Partage du risque, capacité à ajuster le curseur entre vitesse et refonte, transfert de compétences possible par binômage.	Nécessité de règles claires sur qui tranche en cas de conflit, risque de zones grises sur la dette technique non traitée.
Prestataire lead	Délai business court, dette technique connue ou jugée acceptable, équipe interne très sollicitée.	Définition des objectifs métier, gouvernance des données, validation production, gestion de la continuité d’activité.	Responsabilité d’architecture détaillée, plan de réduction de dette ciblé, réalisation, tests et préparation à la mise en production.	Capacité à tenir un délai serré, responsabilisation du prestataire sur la cohérence globale, visibilité sur les engagements de résultat.	Risque de dépendance forte, besoin d’exiger séniorité et transparence sur les choix techniques pour éviter une nouvelle couche de dette.

1. Évaluer votre situation : qualifiez le niveau de dette technique par grande brique (base de données, intégration, interfaces métier), la charge de vos équipes et les contraintes de continuité d’activité (fenêtres de bascule, tolérance à l’incident).
2. Associer un scénario par phase : par exemple, pilotage interne fort sur l’audit et la conception détaillée, modèle mixte sur le build, prestataire lead encadré lors des pics de livraison, puis recentrage interne sur la mise en production et le transfert.
3. Formaliser les bascules : définissez noir sur blanc les critères qui déclenchent le passage d’un scénario à l’autre (audit terminé, dette critique cartographiée, premiers lots en production) pour garder la main sur la répartition des risques.

Clarifier qui décide, qui exécute et qui porte le risque

Pour un SI chargé en dette technique, vous devez poser explicitement, brique par brique, qui tranche, qui fait et qui assume les conséquences. Sans cela, les angles morts se transforment en incidents de production ou en surcoûts non anticipés.

Un moyen pratique consiste à décliner les responsabilités pour chaque domaine du projet :

Brique	Qui décide	Qui exécute	Qui porte le risque principal
Architecture applicative et technique	Comité d’architecture piloté par la DSI	Équipe mixte avec développeurs seniors côté prestataire et référents internes	Partagé : DSI pour les choix structurants, prestataire pour la conformité du code aux décisions
Traitement de la dette technique	DSI (priorisation par risque et impact métier)	Prestataire pour les chantiers ciblés, avec validation interne des approches	Prestataire sur la qualité des remédiations, DSI sur le périmètre accepté comme « dette résiduelle »
Intégration au SI (interfaces, flux, batchs)	DSI sur les patterns et règles d’intégration	Prestataire sur le développement, interne sur la configuration des systèmes existants	DSI sur les impacts transverses, prestataire sur la robustesse des adaptateurs livrés
Tests (fonctionnels, non régression, performance)	DSI (stratégie et critères de couverture)	Prestataire pour l’automatisation et l’exécution, métiers pour la validation	Prestataire sur la qualité des tests, DSI sur la décision de passer en production
Exploitation et continuité d’activité	DSI (SLA, fenêtre de déploiement, plans de secours)	Équipe d’exploitation interne, avec support de mise en prod par le prestataire	DSI sur la disponibilité globale, prestataire sur les incidents liés aux évolutions livrées
Gouvernance des données IA	DSI et RSSI pour les règles d’usage, de stockage et de traçabilité	Prestataire pour la mise en œuvre technique, interne pour l’administration des droits	DSI sur la conformité et la protection des données, prestataire sur la bonne application des règles

1. Formalisez ce tableau pour votre projet en ajoutant vos modules critiques (par exemple facturation, référentiels, agents IA) : vous obtenez une vue claire des zones à renégocier.
2. Exigez que l’équipe senior qui décide de l’architecture contribue aussi au code sur les composants centraux : vous réduisez l’écart entre décisions théoriques et livrables réels.
3. Pour chaque ligne, définissez un scénario d’incident type et qui répond (délai, canal, responsabilité de correction) : vous limitez les débats en production.

Utiliser l’audit de l’existant comme levier de renégociation

L’audit initial ne sert pas qu’à « comprendre le SI » : il doit être posé comme phase contractuelle, avec la possibilité d’ajuster périmètre, charges et répartition des risques une fois les angles morts révélés.

1. Fixer un mandat d’audit et un droit explicite à révision

Précisez dans le contrat qu’une première phase courte est dédiée à l’analyse de l’existant, avec livrables datés (cartographie, liste de risques, estimation de dette technique) et une clause de révision de budget, planning et engagements après cette phase.

Résultat attendu : vous créez un moment officiel où les hypothèses sont revalidées, plutôt que de découvrir « trop tard » des dépendances coûteuses.

2. Structurer l’audit autour des zones de risque

Ciblez en priorité les bases de données, les couches d’intégration, les interfaces historiques métier, les jobs techniques en production et les flux de données sensibles pour les projets IA.

Résultat attendu : une liste priorisée de points durs avec pour chacun : impact métier potentiel, risques de régression, effort de remise à niveau ou de contournement.

3. Lier conception détaillée et engagements du prestataire

Organisez une phase de conception détaillée juste après l’audit, menée par l’équipe qui développera. Faites-y entériner les choix d’architecture, les trajectoires de réduction de dette technique et les scénarios de cohabitation ancien/nouveau système.

Résultat attendu : moins d’écart entre architecture « sur le papier » et code livré, et une base argumentée pour dire ce qui relève de la dette historique (risque DSI) et du nouveau design (risque prestataire).

4. Conditionner la suite du projet à des critères de sortie d’audit

Définissez quelques critères de passage obligatoires : liste des composants hors support identifiés, cartographie des dépendances critiques, estimation de charge par lot, plan de continuité d’activité pour les mises en production.

Résultat attendu : si ces critères ne sont pas atteints, vous avez la possibilité formelle de revoir l’organisation (plus de pilotage interne, renfort d’expertise, phasage différent) avant de vous engager sur plusieurs années.

Poser des garde-fous contractuels et opérationnels

Pour limiter les angles morts sans étouffer vos équipes, vous avez besoin de garde-fous écrits, mesurables et reliés à la réalité de votre SI existant, pas seulement d’un contrat forfaitaire ou d’un backlog agile.

1. Fixer des critères de sortie de phase vérifiables

Pour chaque étape (audit, conception, itérations de dev, préparation de mise en production), définissez 3 à 5 critères concrets : livrables attendus, couverture de tests minimale, scénarios legacy pris en compte, niveau de dette technique résiduelle documenté. L’accès à la phase suivante dépend de la validation de ces critères par la DSI, avec un procès-verbal partagé.

2. Suivre des indicateurs de risque simples mais réguliers

Formalisez quelques métriques suivies à chaque comité : tickets bloquants liés à l’existant, temps moyen de résolution en environnement d’intégration, volume de contournements techniques ajoutés, disponibilité des référents métier. Ces indicateurs déclenchent des plans d’action écrits (renfort d’équipe, replanning, réduction de périmètre) quand un seuil est dépassé.

3. Écrire des règles d’arbitrage explicites

Prévoyez qui tranche quand il faut choisir entre dette technique, délai ou couverture fonctionnelle : rôle côté DSI, rôle côté prestataire, délai maximal de décision, option par défaut si personne ne tranche. Documentez chaque arbitrage avec son impact accepté (dette reportée, tests réduits, jalon décalé) pour éviter les reproches a posteriori.

4. Sécuriser les environnements d’intégration et de production

Imposez un environnement d’intégration continue représentatif du legacy (données, interfaces, batchs) et un environnement de pré-production calqué sur la production. Le prestataire est responsable de la non-régression sur ces environnements, la DSI garde la main sur les règles de cohabitation ancien/nouveau système et sur les fenêtres de bascule.

5. Organiser un transfert progressif de compétences

Planifiez, dans le contrat, des jalons de montée en compétence interne : binômage sur les développements sensibles, revue de code ciblée, rédaction de guides d’exploitation, sessions de simulation d’incident. L’objectif est qu’à la fin du projet, vos équipes sachent opérer, diagnostiquer et faire évoluer le système sans dépendre du prestataire.

Vous pouvez formaliser ce schéma de garde-fous pour un projet en cours, puis le confronter à un audit externe de l’existant, appuyé si besoin par un outil spécialisé.