Choisir un prestataire de développement sur mesure sans risque pour le SI

Pour limiter le risque sur votre SI, votre partenaire de développement doit prouver sa capacité à concevoir et livrer un logiciel métier sur mesure qui s’intègre proprement à l’existant, sans rupture de service. La sélection se joue moins sur le discours commercial que sur la solidité de l’architecture proposée, la prise en compte de votre dette technique et la façon dont les migrations seront gérées.

Vous travaillez déjà avec des applications critiques, parfois legacy, que vous ne pouvez pas arrêter pendant six mois. Vous avez besoin d’un prestataire qui comprend vos contraintes de production, sait phaser une refonte, sécuriser les interfaces entre systèmes et garantir une mise en production stable sur plusieurs années.

Cet article fait partie du dossier Outil standard ou sur mesure : comment décider en DSI.

Clarifier le contexte SI et le périmètre du projet

Avant de comparer des prestataires, vous devez figer un cadre technique et métier clair : type de projet, contraintes de votre SI, dette technique et niveau de tolérance au risque sur la continuité de service. Ce cadrage sert ensuite de grille de lecture pour écarter vite les candidats hors sujet.

1. Identifier le type de projet et son horizon de vie

• Qualifiez votre besoin : nouveau logiciel métier interne, refonte d’un legacy, pipeline de données, projet IA connecté au SI (agent, RAG, automatisation).
• Estimez la durée de vie visée : plusieurs années d’usage continu pour un logiciel structurant impliquent des choix d’architecture et de maintenabilité robustes.
• Résultat attendu : un descriptif court (une page) qui résume usage cible, criticité métier et durée d’engagement probable.

2. Cartographier l’existant et les points d’intégration

• Listez les applications concernées, leurs interfaces actuelles (API, fichiers, messages), les bases de données touchées et les flux sensibles (facturation, identité, données clients).
• Identifiez pour chaque système si vous visez : maintien, remplacement progressif, ou extinction à terme.
• Résultat attendu : un schéma simple des flux SI impactés, avec pour chaque brique un niveau de dépendance au futur projet.

3. Qualifier la dette technique et les zones à risque

• Repérez les composants obsolètes, non documentés, non testés ou dépendants d’une seule personne.
• Classez-les en trois catégories : à encapsuler, à refondre par étapes, à isoler strictement.
• Résultat attendu : une liste priorisée des dettes qui peuvent faire dérailler une migration ou une intégration IA.

4. Fixer les exigences de continuité et de sécurité

• Posez vos seuils : plage de maintenance acceptable, tolérance à l’indisponibilité, contraintes réglementaires et de localisation des données.
• Précisez les environnements à respecter : on-premise, cloud privé, cloud public restreint, segmentations réseau, politiques d’accès.
• Résultat attendu : un ensemble de contraintes non négociables à transmettre aux prestataires dès le premier échange.

5. Définir un périmètre fonctionnel et technique de phase 1

• Séparez ce qui doit être livré dans la première phase de ce qui peut attendre : fonctionnalités cœur métier, flux critiques, premiers cas d’usage IA.
• Limitez la phase 1 à un périmètre testable en production sans mettre en danger l’existant.
• Résultat attendu : un périmètre de démarrage précis, qui servira de base à un premier projet pilote avec un prestataire.

Qualifier rapidement les prestataires avant la due diligence

Votre objectif à ce stade est de filtrer les candidats qui ne tiendront pas la charge sur votre SI. Vous cherchez à vérifier en quelques échanges si le prestataire comprend votre contexte, a déjà livré des projets comparables en production et sait gérer un existant chargé de dette technique.

1. Valider l’adéquation au contexte SI et aux contraintes

• Demandez dans quels environnements techniques vos interlocuteurs ont déjà livré : hébergement on-premise, cloud public, infrastructures souveraines, SSO, annuaires, bus de messages, etc.
• Vérifiez les contraintes déjà rencontrées : conformité, sécurité, cloisonnement des données, audits internes.
• Résultat attendu : vous écartez les prestataires qui ne connaissent que des projets « greenfield » sans intégration lourde.

2. Comparer les types de projets livrés à vos besoins

• Faites préciser la taille et la nature des projets récents : logiciel métier interne, refonte progressive de legacy, plateforme de données, projet IA connecté au SI.
• Demandez un ou deux exemples concrets de mise en production avec volume d’utilisateurs, durée du projet, ancienneté du système remplacé.
• Résultat attendu : vous identifiez ceux qui ont déjà géré un engagement sur plusieurs années dans un contexte proche du vôtre.

3. Tester la sensibilité à la dette technique et aux migrations

• Posez une question simple : « Comment abordez-vous un SI legacy que vous ne contrôlez pas complètement ? » et écoutez si la réponse parle de cartographie, de coexistence, de bascules progressives.
• Demandez un exemple où une migration a été réalisée sans interruption de service métier.
• Résultat attendu : vous éliminez les discours de « remplacement intégral » sans plan de cohabitation.

4. Identifier qui prend les décisions d’architecture

• Demandez qui conçoit l’architecture et qui écrit le code sur un projet type : même équipe senior ou séparation architecte / réalisation déléguée.
• Faites préciser comment les choix d’architecture sont documentés et validés avec vos équipes.
• Résultat attendu : vous retenez les prestataires où les responsables d’architecture restent impliqués dans le code et les revues.

5. Mesurer la maturité spécifique sur les projets IA (si concerné)

• Si votre projet inclut de l’IA, demandez des exemples précis : agents connectés à des outils métier, systèmes de recherche augmentée, pipelines de données.
• Vérifiez comment ces systèmes sont intégrés à la sécurité existante, aux logs, à la supervision, et comment sont gérées les données sensibles.
• Résultat attendu : vous filtrez les acteurs qui traitent l’IA comme une preuve de concept isolée, sans ancrage dans le SI.

À l’issue de cette qualification rapide, vous ne gardez qu’une courte liste de prestataires avec des références comparables, une culture de la cohabitation avec l’existant et une continuité entre architecture et développement. Ceux-là méritent une due diligence technique détaillée.

Mener la due diligence technique sur l’architecture proposée

Votre objectif est de comprendre comment l’architecture tiendra dans votre SI sur plusieurs années, pas de juger un schéma joli sur un slide. Voici les questions concrètes à poser et les signaux d’alerte à repérer.

1. Clarifier le découpage applicatif et les dépendances

• Question : Comment les modules sont-ils découpés et quels contrats d’interface les lient ?
• À vérifier : présence de frontières claires (API, messages, schémas d’événements) et de responsables identifiés par domaine fonctionnel.
• Signal de risque : schéma « tout en un » ou microservices proposés sans expliquer la granularité ni la gestion des dépendances.

2. Tester l’intégration au SI existant (API, data, IAM)

• Question : Quels systèmes existants sont appelés, par quel protocole, avec quels contrats de données et quelles limites de charge ?
• À vérifier : prise en compte de vos bus, API, annuaires, référentiels maîtres, et existence de stratégies de repli quand un composant legacy est indisponible.
• Signal de risque : intégrations décrites en une phrase générique « via API » sans parler de versionning, timeouts, erreurs, quotas.

3. Évaluer la stratégie de données et de performance

• Question : Où résident les données maîtres, comment sont gérées les synchronisations, indexations et archives ?
• À vérifier : séparation clair entre stockage transactionnel et analytique, plan de partitionnement ou d’indexation, scénarios de montée en charge.
• Signal de risque : tables partagées entre plusieurs services, absence de réflexion sur les pics de charge connus de votre activité.

4. Inspecter la sécurité et la gestion des secrets dès l’architecture

• Question : Comment sont gérés l’authentification, l’autorisation, le chiffrement, les secrets et les journaux de sécurité ?
• À vérifier : intégration prévue avec vos référentiels d’identités, cloisonnement réseau, journalisation exploitable par vos équipes de sécurité.
• Signal de risque : sécurité renvoyée « à la phase d’implémentation » ou concentrée sur la seule authentification utilisateur.

5. Mesurer la maintenabilité, la réversibilité et la dette future

• Question : Quelles sont les dépendances non standards, et que se passe-t-il si vous devez changer de fournisseur, de modèle IA ou de base de données ?
• À vérifier : isolation des briques spécifiques derrière des façades ou adaptateurs, documentation prévue, tests automatisés au niveau des contrats d’interface.
• Signal de risque : forte dépendance à une technologie ou à un modèle IA sans couche d’abstraction, absence de plan de migration ou de retrait du système.

6. Vérifier la continuité entre architecture et code

• Question : Qui a conçu l’architecture et qui développe au quotidien, avec quels rituels pour ajuster les choix ?
• À vérifier : présence de profils seniors impliqués à la fois dans les décisions d’architecture, les revues de code et la définition des tests.
• Signal de risque : architecture vendue par une équipe « avant-vente » différente des équipes qui écrivent le code, sans gouvernance technique claire.

Vérifier la maîtrise de l’intégration SI, de la dette technique et des migrations

Vous devez tester si le prestataire sait travailler avec un existant imparfait sans casser la production. Concentrez-vous sur sa manière de cartographier le SI, de planifier une refonte par étapes et d’orchestrer les migrations applicatives et données en visant zéro interruption de service.

1. Exiger une cartographie technique et fonctionnelle de l’existant

• Action : demander un document qui liste applications, flux, dépendances, versions, données critiques, SLA et points de fragilité.
• Résultat attendu : une vision claire des zones à risque (legacy, mono-blocs, interfaces fragiles) et des contraintes qui encadrent le projet.

2. Demander un plan de refonte progressive, pas un big bang

• Action : exiger un découpage en lots fonctionnels, avec coexistence ancien/nouveau système et stratégies de repli explicites.
• Résultat attendu : une trajectoire par paliers, avec des jalons mesurables et la possibilité d’arrêter ou d’ajuster sans tout remettre en cause.

3. Faire détailler la stratégie de migration de données

• Action : demander comment seront gérés mapping, qualité, reprise historique, synchronisation temps réel ou quasi temps réel, et tests de non-régression.
• Résultat attendu : un scénario de migration écrit (scripts, fenêtres de bascule, plan de retour arrière) compatible avec vos contraintes d’exploitation.

4. Valider l’intégration avec les systèmes et outils existants

• Action : faire préciser pour chaque interface le mode d’intégration (API, messages, fichiers, bus), les responsabilités, la supervision et la gestion des erreurs.
• Résultat attendu : des flux documentés, monitorables, avec des contrats d’interface stables et un plan de tests d’intégration automatisés.

5. Tester la prise en compte des contraintes d’exploitation et de sécurité

• Action : vérifier comment le prestataire intègre vos environnements (on-premise, cloud, réseaux), vos contraintes d’habilitation, de journalisation et de sauvegarde.
• Résultat attendu : une solution déployable dans vos conditions réelles, avec surveillance, sauvegarde, restauration et tracabilité déjà pensées.

6. Exiger des scénarios de migration sans interruption de service

• Action : demander des exemples précis de bascules à chaud ou à froid réalisées, avec maintien de l’activité métier.
• Résultat attendu : un plan qui prévoit tolérance aux pannes, tests de charge, répétition des bascules et validation avec vos équipes avant le jour J.

Valider la capacité à livrer, exploiter et maintenir en production

Avant de vous engager, vous devez vérifier que le prestataire sait passer d’un POC à un service stable : déploiements maîtrisés, surveillance en production, gestion d’incidents, transfert de compétences et support sur la durée.

1. Demander un déroulé précis d’un cycle d’itération

Obtenez un exemple concret d’itération type sur un précédent projet : ateliers, maquettage, développement, tests, mise en pré‑production, validation métier, déploiement. Résultat attendu : vous comprenez qui décide quoi, à quel moment, et comment les changements sont arbitrés pour éviter la dérive ou les surprises en fin de projet.

2. Inspecter le pipeline de tests et de déploiement

Demandez comment les tests unitaires, d’intégration, de non‑régression et de performance sont déclenchés, et sur quels environnements (intégration, pré‑prod, prod). Résultat attendu : un pipeline continu, automatisé, avec des points de contrôle clairs avant chaque mise en production, y compris pour les modèles IA et les pipelines de données.

3. Évaluer la gestion des risques et des incidents

Faites décrire un incident réel géré par le prestataire : détection, diagnostic, rollback, correctif, communication avec la DSI. Résultat attendu : procédures formalisées, capacité de retour arrière rapide, logs exploitables et indicateurs de disponibilité et de performance suivis dans la durée.

4. Clarifier l’exploitation et la supervision en cible

Demandez quels tableaux de bord seront fournis : erreurs applicatives, latence, saturation des ressources, dérive de qualité sur les réponses IA. Résultat attendu : un dispositif de supervision compatible avec vos outils de monitoring et vos pratiques d’exploitation, sans trou de visibilité.

5. Organiser le transfert de compétences et la réversibilité

Exigez un plan de transmission : documentation à jour, revue de code avec vos équipes, sessions d’exploitation, droits d’accès aux dépôts, scripts d’infrastructure, procédures de reprise et d’upgrade. Résultat attendu : vous pouvez maintenir, faire évoluer ou confier le logiciel et les briques IA à un autre prestataire sans dépendance opaque.

6. Tester la collaboration sur un pilote cadré

Lancez un projet limité (fonctionnalité métier, micro‑service, agent IA sur un périmètre réduit) avec objectifs, budget et critères de succès écrits. Résultat attendu : vous validez sur pièces la capacité du prestataire à livrer, déployer sans rupture de service et coopérer avec vos équipes.

Pour structurer vos choix, vous pouvez formaliser cette grille en critères et questions, puis la confronter lors d’un cadrage technique ou d’un audit avec un prestataire, en vous appuyant si besoin sur un outil spécialisé pour suivre les risques et décisions.