Comment choisir un partenaire logiciel et IA en production

Pour trouver un prestataire capable de prendre en charge un projet logiciel structurant avec engagement sur la mise en production, votre priorité n’est pas la stack mais la capacité à tenir l’activité sans rupture. Le bon partenaire sait gérer votre legacy, réduire la dette technique et garantir que les choix d’architecture se retrouvent dans le code réellement déployé.

Vos projets logiciels et IA engagent votre SI sur plusieurs années, avec des systèmes déjà en place, des dépendances, des contraintes de données et de souveraineté. Vous avez besoin d’un interlocuteur qui commence par un audit sérieux de l’existant, propose une trajectoire réaliste de migration, s’engage sur la continuité de service et reste responsable jusqu’à la mise en production et au transfert de compétences.

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

Clarifier le périmètre et les risques avant de lancer la sélection

Avant de comparer des prestataires, vous devez savoir sur quoi vous engagez votre SI pour plusieurs années : périmètre fonctionnel, dette technique à résorber, risques de rupture de service et ambitions sur les données et l’IA. Sans ce cadrage, votre grille de sélection restera théorique et les réponses des partenaires seront difficilement comparables.

1. Poser l’horizon de temps et les objectifs métier

Définissez la durée pendant laquelle le système doit rester en production sans refonte majeure, ainsi que les gains attendus : disponibilité cible, réduction de la dette, nouveaux usages data ou IA, contraintes de souveraineté. Résultat : un périmètre temporel et stratégique clair que vous pouvez exposer aux partenaires.

2. Cartographier l’existant technique et fonctionnel

Listez les applications concernées, leurs dépendances (bases de données, messages, batchs, API), les flux critiques, les fenêtres de maintenance tolérées. Résultat : une vision synthétique des points de couplage que le partenaire devra gérer sans casser l’existant.

3. Qualifier la dette technique et les zones à risque

Identifiez les modules obsolètes, technologies en fin de vie, absence de tests, documentation manquante, équipes expertes en voie de départ. Classez ces éléments par impact sur la disponibilité et la maintenabilité. Résultat : une liste de risques priorisés qui servira de base aux questions à poser sur la gestion du legacy.

4. Repérer les systèmes et processus intouchables

Marquez les briques où l’objectif est zéro interruption : facturation, paiement, production, relation client, etc. Précisez les volumes, les pics d’activité, les obligations réglementaires. Résultat : un « périmètre critique » pour lequel vous exigerez des stratégies de migration et de rollback détaillées.

5. Aligner ce cadrage avec votre roadmap produit et data

Reliez les évolutions prévues (nouvelles fonctionnalités, ouverture d’API, cas d’usage IA, consolidation de données) au projet structurant. Résultat : une trajectoire produit et data que le partenaire devra intégrer, et qui deviendra un critère explicite de sélection.

6. Formaliser une première grille de critères

À partir de ce travail, rédigez une grille simple : capacité à gérer les dépendances critiques, à réduire la dette, à accompagner les usages data/IA, à tenir l’horizon de temps. Résultat : un document prêt à être confronté aux prestataires lors d’un échange exploratoire ciblé sur l’existant, la dette et la mise en production.

Tester la capacité du partenaire à comprendre et gérer le legacy

Vous devez vérifier dès le départ si un partenaire sait lire votre existant, mesurer la dette technique et se caler sur votre roadmap métier. Sans ce socle, chaque décision ultérieure d’architecture ou d’IA risque d’être déconnectée du terrain.

1. Exiger un audit court, borné et structuré

• Action : cadrer un audit initial de quelques jours avec un périmètre clair : applications critiques, flux principaux, données sensibles, contraintes de disponibilité.
• Résultat attendu : une vue synthétique des briques qui portent le risque métier et technique, et une première estimation de la dette à traiter, sans entrer encore dans la refonte détaillée.

2. Observer la façon dont le partenaire cartographie le SI

• Action : demander un schéma des dépendances (applications, bases, batchs, interfaces temps réel, briques IA existantes ou prévues) et la mise en évidence des points de couplage fort.
• Résultat attendu : une cartographie simple, lisible, qui met en avant les zones dangereuses pour une migration ou une nouvelle brique IA, et pas seulement un inventaire d’outils.

3. Relier dette technique et risques métiers

• Action : imposer que chaque élément de dette identifié soit relié à un impact métier concret : indisponibilité potentielle, lenteur, difficulté de déploiement, risque de régression.
• Résultat attendu : une liste courte de dettes bloquantes, priorisées non pas par « élégance technique » mais par effet sur vos SLA, sur vos équipes et sur la roadmap produit.

4. Tester l’intégration à la roadmap et à la gouvernance

• Action : présenter votre roadmap à 12–24 mois (fonctionnelle, data, IA) et demander comment le partenaire l’intègre dans son plan d’intervention sur le legacy.
• Résultat attendu : un plan qui séquence réduction de dette, nouvelles fonctionnalités et projets IA, sans gel prolongé de votre capacité à livrer et sans rupture de service.

5. Demander une synthèse de risques et de scénarios

• Action : exiger, en sortie d’audit, un document court : risques majeurs, scénarios de migration (big bang vs progressif), points de contrôle en production, impacts sur les équipes internes.
• Résultat attendu : une base concrète pour comparer les partenaires entre eux, en fonction de leur compréhension de votre legacy et de leur capacité à sécuriser l’activité pendant plusieurs années.

Vérifier la continuité entre architecture et code livré

Pour un projet structurant, vous devez vérifier que les choix d’architecture ne restent pas théoriques et se traduisent bien dans le code, jusqu’à la mise en production. L’objectif est simple : la même équipe conçoit, développe, teste et accompagne le déploiement, avec un dispositif de delivery qui expose vite les dérives.

1. Exiger une équipe resserrée architecture + développement

• Action : demander l’organigramme opérationnel du projet avec les noms, rôles et temps alloué de chaque profil senior, et vérifier que les architectes proposés codent aussi sur le cœur du système.
• Résultat : vous limitez le risque d’un « bureau d’étude » déconnecté des contraintes de delivery et de l’existant.

2. Analyser la chaîne décisionnelle technique

• Action : questionner le partenaire sur la façon dont sont tranchés les choix d’architecture en cours de route (performance, sécurité, dette technique, IA, data) et qui valide les compromis dans le code.
• Résultat : vous identifiez si les décisions sont prises par ceux qui écrivent le code ou remontées à un comité lointain qui ralentit et rigidifie le projet.

3. Inspecter le cycle de delivery et les garde-fous

• Action : demander un exemple détaillé de sprint récent : user stories, branches de code, revues, pipelines de tests, critères de « done », gestion de la dette technique, y compris pour les composants IA.
• Résultat : vous voyez si les itérations courtes, les revues de code systématiques et les tests automatisés réduisent l’écart entre conception et implémentation.

4. Relier les décisions d’architecture aux artefacts de code

• Action : exiger un exemple de décision d’architecture documentée (par exemple un choix de découpage en services, un pattern d’intégration au SI ou un design d’agent IA) et demander où cette décision est visible dans le dépôt de code.
• Résultat : vous vérifiez que chaque choix d’architecture a une trace concrète dans le code, dans les tests et dans le monitoring de production.

5. Contrôler la gestion continue de la dette technique

• Action : demander comment sont identifiées, priorisées et traitées les tâches de réduction de dette technique dans chaque sprint, y compris sur le legacy intégré au projet.
• Résultat : vous évitez un système qui semble propre à la livraison initiale mais qui se dégrade vite sur 3 à 7 ans d’exploitation.

6. Tester la cohérence jusqu’à la mise en production

• Action : faire décrire un scénario complet de passage en production récent : environnement de préproduction, scripts de migration, stratégies de rollback, supervision, gestion des incidents.
• Résultat : vous évaluez si ceux qui ont conçu l’architecture sont aussi capables d’orchestrer un déploiement réel sans interruption d’activité.

Sécuriser la mise en production, les migrations et l’exploitation

Pour limiter le risque, votre critère central doit être la capacité du partenaire à déployer sans coupure, migrer les données sans perte et laisser une équipe autonome sur un système exploitable, y compris pour les briques IA et les contraintes de souveraineté.

Exiger un plan de déploiement sans interruption

Demandez un scénario précis de mise en production : séquence, durée, points de bascule, plan de repli. Vérifiez que le partenaire maîtrise les approches de déploiement progressif (par exemple blue/green ou canary) et sait les adapter à votre contexte (monolithe, microservices, API exposées, postes en agence, etc.). Le résultat attendu : un runbook de mise en production avec responsabilités, prérequis et temps estimés par étape.

Challenger la stratégie de migration de données

Demandez comment seront gérés : volumes, fenêtres de migration, reconcil des écarts, reprise sur incident. Imposez au minimum :

• un environnement de dress rehearsal pour rejouer la migration sur une copie de vos données ;
• une stratégie de synchronisation incrémentale si la coupure n’est pas possible ;
• des scripts de migration versionnés et testés dans le pipeline CI.

Le résultat attendu : un plan de migration chiffré en lots, avec critères de succès mesurables et procédure de rollback.

Vérifier l’intégration exploitation / supervision

Demandez comment seront gérés logs, métriques, traces, alertes et capacités de diagnostic. Vérifiez que la solution s’intègre à vos pratiques existantes (ITSM, supervision, gestion des incidents) et que les dashboards d’exploitation sont prévus avant la mise en production. Le résultat attendu : une liste claire des indicateurs surveillés et des seuils d’alerte partagés avec vos équipes.

Encadrer la souveraineté et les briques IA

Pour les composants IA, demandez où sont hébergées les données, comment sont isolés les environnements et comment sont gérés les jeux d’entraînement et les logs de requêtes. Vérifiez la compatibilité avec vos contraintes réglementaires et votre politique de souveraineté. Le résultat attendu : une architecture IA documentée, compatible avec vos exigences de localisation et de gouvernance des données.

Structurer le transfert de compétences

Imposez un dispositif formalisé : sessions de prise en main pour vos équipes, documentation maintenue dans le dépôt, co-pilotage des premières mises en production, support renforcé sur les premiers mois. Le résultat attendu : un plan de transfert daté, avec livrables, profils formés et critères de passage en « régime nominal » pour l’exploitation.

Construire et utiliser une grille de sélection pour challenger les prestataires

Pour comparer vos partenaires sans vous perdre dans les discours sur l’agile ou la stack, formalisez une grille de critères pondérés et utilisez-la en soutenance comme fil rouge de vos questions.

Procédez en quatre étapes simples :

1. Définir vos axes de décision

   Listez 4 à 6 axes alignés sur vos enjeux réels, par exemple : gestion du legacy et de la dette, continuité architecture/code, sécurisation de la mise en production, capacité IA et data, gouvernance et modèle de collaboration. L’objectif est de couvrir tout le cycle : audit, conception, développement, déploiement, exploitation.

2. Poser des questions factuelles pour chaque axe

   Préparez des questions qui obligent à descendre au concret :

• Legacy : « Décrivez un audit d’existant réalisé sur un SI proche du nôtre. Quelles sorties avez-vous produites ? »
• Architecture/code : « Qui prend les décisions d’architecture et quel est son temps réel passé à coder ? »
• Mise en production : « Comment organisez-vous une migration sans interruption d’activité pour un système critique ? »
• IA et données : « Comment intégrez-vous une brique IA à la gouvernance de données existante et aux contraintes de souveraineté ? »
• Transfert : « Quels livrables et quelles sessions prévoyez-vous pour rendre l’équipe interne autonome ? »

3. Pondérer et formaliser la grille

   Attribuez un poids à chaque axe selon vos priorités (par exemple projet très sensible au legacy ou à la souveraineté). Utilisez ensuite un tableau commun au comité de sélection pour noter chaque prestataire.

Critère	Poids	Questions de soutenance	Preuves attendues
Gestion legacy / dette	Fort	Exemples d’audit, plan de réduction de dette sur plusieurs années	Cartographies d’existant, plans de migration, rétroplannings
Continuité archi / code	Fort	Rôle des seniors, organisation des revues de code	Organigrammes d’équipe, extraits de pratiques de revue/tests
Mise en production / exploitation	Fort	Stratégie de déploiement progressif, gestion des incidents	Runbooks, modèles de plan de déploiement, exemples de rollback
IA, données, souveraineté	Variable	Intégration SI, pipelines, contraintes d’hébergement	Schémas d’architecture, exemples de pipelines IA en production
Transfert de compétences	Moyen	Plan de handover, formats de documentation	Exemples de guides, planning de formation

Diffusez cette grille à tous les membres du comité, utilisez-la en entretien, puis documentez votre choix à partir des scores et des preuves collectées ; un outil spécialisé peut ensuite vous aider à structurer ces critères et à comparer les réponses des prestataires.