Ressource pour dirigeants et DSI
Cadrer un projet logiciel ou IA avec votre 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.
Comment l’utiliser
Choisissez un parcours prioritaire. Répondez avec le métier et la DSI, nommez un responsable pour chaque décision et gardez les inconnues visibles. Le modèle Markdown est un fichier texte éditable dans votre outil habituel, sans inscription ni envoi automatique de vos réponses.
Rédaction : Ikovaline · Mise à jour de cette grille :
Point 1 / 8
Le problème métier et le périmètre
- Quel parcours doit changer, pour quels utilisateurs et dans quelle situation concrète ?
- Comment mesurez-vous aujourd’hui ce parcours, avec quelle période et quel échantillon ?
- Qu’est-ce qui entre dans la première version, et qu’est-ce qui en est explicitement exclu ?
- 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 à prendre
- 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.
Point 2 / 8
Les interfaces avec le système existant
- Quels ERP, CRM, annuaires, outils de paiement ou fichiers doivent échanger avec le produit ?
- Quel système fait autorité pour chaque donnée, et qui peut la modifier ?
- Que se passe-t-il si une API est indisponible, change de version ou reçoit deux fois la même demande ?
- 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 à prendre
- 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.
Point 3 / 8
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 ?
- Comment traitez-vous les doublons, les lignes invalides et les pièces manquantes ?
- Qui contrôle le résultat, et comment revient-on à la situation précédente si la bascule échoue ?
- 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 à prendre
- 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.
Point 4 / 8
Les identités et les permissions
- Quels rôles peuvent lire, créer, modifier, exporter et administrer les données ?
- Faut-il se connecter à l’annuaire existant et séparer plusieurs entités ou clients ?
- Comment révoque-t-on un accès et retrouve-t-on l’auteur d’une action sensible ?
- 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 à prendre
- 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.
Point 5 / 8
L’exploitation et la continuité
- Quelles périodes, quels volumes et quels appareils sont critiques pour l’activité ?
- Quelle indisponibilité et quelle perte de données pouvez-vous réellement accepter ?
- Qui surveille le service, reçoit une alerte et intervient quand un parcours échoue ?
- 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 à prendre
- 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.
Point 6 / 8
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 ?
- Quelles données peut-elle consulter, avec quels droits, et où sont-elles traitées ?
- Quels cas d’erreur, coûts, délais et critères d’arrêt testez-vous avant d’élargir son usage ?
- 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 à prendre
- 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.
Point 7 / 8
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 ?
- Qui possède les dépôts, comptes d’hébergement, domaines et accès d’administration ?
- Quels documents et opérations permettent à une autre équipe de reprendre le produit ?
- 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 à prendre
- 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.
Point 8 / 8
Le coût d’ensemble et les dépendances
- Quels postes couvrent le devis, et quels postes restent à la charge de votre organisation ?
- Quels coûts récurrents varient avec les utilisateurs, le stockage, les interfaces ou l’usage IA ?
- Comment exportez-vous vos données ou changez-vous de fournisseur, et à quel coût estimé ?
- 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 à prendre
- 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.
Ce qui doit rester explicite avant le devis
Le périmètre retenu, les exclusions, les dépendances, les hypothèses de charge, les critères de livraison et les risques encore ouverts. Une réponse manquante devient un point à instruire, pas une fonctionnalité supposée incluse.
Récupérer le modèle à compléter (.md)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.
Références et prolongements
- OpenAPI Specification
Décrire les interfaces HTTP, sans présumer de la qualité de leur implémentation.
- NIST AI Risk Management Framework
Structurer une démarche volontaire de gestion des risques IA, sans certification implicite.
Votre périmètre est-il assez clair pour être chiffré ?
Apportez le parcours prioritaire et les contraintes déjà connues. Le premier échange sert à cadrer la demande, pas à remplacer un audit de votre système.
Appel de cadrage offert · Mission approfondie sur devis