# Cadrer un projet logiciel ou IA avec votre DSI

Version : 2026-10-05

Source : https://ikovaline.com/ressources/cadrage-projet-dsi

Avant de comparer des devis, mettez les mêmes contraintes sur la table. Cette grille aide la direction, la DSI et les équipes métier à cadrer un logiciel sur mesure, un SaaS B2B ou un usage IA connecté au système existant. Chaque rubrique associe des questions, une preuve à demander et une décision à prendre.

Modèle à compléter en interne. Aucune réponse n’est transmise à Ikovaline par ce document.

Projet :
Responsable métier :
Interlocuteur DSI :
Date de cadrage :

## 1. Le problème métier et le périmètre

- Quel parcours doit changer, pour quels utilisateurs et dans quelle situation concrète ?
  Réponse :


- Comment mesurez-vous aujourd’hui ce parcours, avec quelle période et quel échantillon ?
  Réponse :


- Qu’est-ce qui entre dans la première version, et qu’est-ce qui en est explicitement exclu ?
  Réponse :


Preuve à demander : Un parcours décrit de bout en bout, des exemples anonymisés et une mesure de départ. Un gain annoncé sans situation de référence n’est pas une preuve.

Décision : Le responsable métier fixe le résultat attendu ; la direction tranche le périmètre et le budget. Le prestataire décrit ce qu’il peut livrer, pas un ROI garanti.

Responsable désigné :
Décision retenue :
Justificatif ou test :
Point non résolu :

## 2. Les interfaces avec le système existant

- Quels ERP, CRM, annuaires, outils de paiement ou fichiers doivent échanger avec le produit ?
  Réponse :


- Quel système fait autorité pour chaque donnée, et qui peut la modifier ?
  Réponse :


- Que se passe-t-il si une API est indisponible, change de version ou reçoit deux fois la même demande ?
  Réponse :


Preuve à demander : Une carte des flux, la documentation des interfaces disponibles et des scénarios de panne ou de doublon testables. OpenAPI peut documenter un contrat HTTP ; cela ne prouve pas que l’intégration fonctionne.

Décision : La DSI et les propriétaires des systèmes valident les accès et la responsabilité des échanges. Les dépendances non disponibles sont séparées des fonctions livrables immédiatement.

Responsable désigné :
Décision retenue :
Justificatif ou test :
Point non résolu :

## 3. La reprise des données et le retour arrière

- Quelles données faut-il reprendre, depuis quelles sources et avec quelles règles de correspondance ?
  Réponse :


- Comment traitez-vous les doublons, les lignes invalides et les pièces manquantes ?
  Réponse :


- Qui contrôle le résultat, et comment revient-on à la situation précédente si la bascule échoue ?
  Réponse :


Preuve à demander : Un inventaire, un essai sur données anonymisées, des contrôles de rapprochement et un plan de bascule avec retour arrière. Un import qui termine sans erreur ne suffit pas à prouver l’intégrité.

Décision : Le propriétaire des données définit les règles métier ; la DSI valide la bascule et les sauvegardes. La correction de données historiques est chiffrée distinctement si elle dépasse le périmètre.

Responsable désigné :
Décision retenue :
Justificatif ou test :
Point non résolu :

## 4. Les identités et les permissions

- Quels rôles peuvent lire, créer, modifier, exporter et administrer les données ?
  Réponse :


- Faut-il se connecter à l’annuaire existant et séparer plusieurs entités ou clients ?
  Réponse :


- Comment révoque-t-on un accès et retrouve-t-on l’auteur d’une action sensible ?
  Réponse :


Preuve à demander : Une matrice des droits et des tests qui tentent aussi les actions interdites. Une interface qui masque un bouton n’est pas une vérification des droits côté serveur.

Décision : La DSI ou le responsable sécurité valide la politique d’accès. Le responsable métier désigne les administrateurs et les règles de départ des utilisateurs.

Responsable désigné :
Décision retenue :
Justificatif ou test :
Point non résolu :

## 5. L’exploitation et la continuité

- Quelles périodes, quels volumes et quels appareils sont critiques pour l’activité ?
  Réponse :


- Quelle indisponibilité et quelle perte de données pouvez-vous réellement accepter ?
  Réponse :


- Qui surveille le service, reçoit une alerte et intervient quand un parcours échoue ?
  Réponse :


Preuve à demander : Des objectifs définis pour ce projet, un scénario de restauration exécuté et une procédure d’incident avec responsabilités. Une sauvegarde existante n’est pas une restauration vérifiée.

Décision : La direction et la DSI choisissent les objectifs de service et le niveau de support. Hébergement, maintenance et astreinte ne sont pas supposés inclus dans le développement.

Responsable désigné :
Décision retenue :
Justificatif ou test :
Point non résolu :

## 6. L’IA, si elle apporte quelque chose au parcours

- L’IA suggère-t-elle une réponse ou déclenche-t-elle une action sur un système réel ?
  Réponse :


- Quelles données peut-elle consulter, avec quels droits, et où sont-elles traitées ?
  Réponse :


- Quels cas d’erreur, coûts, délais et critères d’arrêt testez-vous avant d’élargir son usage ?
  Réponse :


Preuve à demander : Un jeu d’évaluation représentatif, des résultats datés, des limites documentées, une validation humaine adaptée et un repli sans IA. Le cadre volontaire NIST AI RMF aide à structurer les risques ; le citer n’est pas une certification.

Décision : Le responsable métier et la DSI définissent les actions autorisées et les cas nécessitant une validation humaine. Le fournisseur, les coûts d’usage et les conditions de traitement sont examinés avant la production.

Responsable désigné :
Décision retenue :
Justificatif ou test :
Point non résolu :

## 7. Les critères de livraison et la passation

- Quels parcours et cas d’erreur démontrent que la version livrée répond au besoin ?
  Réponse :


- Qui possède les dépôts, comptes d’hébergement, domaines et accès d’administration ?
  Réponse :


- Quels documents et opérations permettent à une autre équipe de reprendre le produit ?
  Réponse :


Preuve à demander : Des critères observables, une version testable, un inventaire des accès et une procédure de déploiement et de reprise. Une démonstration commerciale ne remplace pas les tests du produit livré.

Décision : Le métier valide les parcours ; la DSI vérifie l’exploitation et la reprise. Les droits sur le code, les licences et les livrables sont explicités dans le contrat.

Responsable désigné :
Décision retenue :
Justificatif ou test :
Point non résolu :

## 8. Le coût d’ensemble et les dépendances

- Quels postes couvrent le devis, et quels postes restent à la charge de votre organisation ?
  Réponse :


- Quels coûts récurrents varient avec les utilisateurs, le stockage, les interfaces ou l’usage IA ?
  Réponse :


- Comment exportez-vous vos données ou changez-vous de fournisseur, et à quel coût estimé ?
  Réponse :


Preuve à demander : Des hypothèses de charge, une séparation développement/exploitation et un scénario de sortie. Comparez des devis sur le même périmètre plutôt que sur un prix d’entrée seul.

Décision : La direction et les achats comparent les scénarios ; la DSI vérifie les dépendances. Les hypothèses et incertitudes restent visibles, sans transformer une estimation en engagement garanti.

Responsable désigné :
Décision retenue :
Justificatif ou test :
Point non résolu :

## Synthèse avant devis

- Périmètre retenu :
- Exclusions :
- Dépendances :
- Hypothèses de charge :
- Critères de livraison :
- Risques ouverts et responsables :
- Décisions à prendre avant engagement :

## Références

- [OpenAPI Specification](https://spec.openapis.org/oas/v3.2.1.html) : Décrire les interfaces HTTP, sans présumer de la qualité de leur implémentation.

- [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) : Structurer une démarche volontaire de gestion des risques IA, sans certification implicite.

Cette grille prépare le cadrage. Elle ne remplace ni une analyse de sécurité propre à votre organisation, ni une revue juridique, ni un audit approfondi. Ne joignez pas de secrets, de données personnelles ou de fichiers clients à une première prise de contact.