Aller au contenu

Cadrer et livrer

Comment cadrer un projet IT avant de demander un devis

Un cadre concret pour clarifier le problème, le périmètre, les risques et les décisions d’un projet numérique avant de comparer des offres.

Par Danilson Da Veiga RamosRelu par Équipe LysliaMis à jour le 24 juillet 2026

Commencer par le problème à résoudre

Un devis fiable ne commence pas par une liste de technologies. Il commence par une situation observable : une opération trop lente, un parcours qui abandonne, des données dispersées ou un produit qui ne peut plus évoluer sans risque.

Formulez le problème en une phrase, puis décrivez qui le rencontre, à quel moment et avec quelle conséquence. Cette formulation sert de filtre lorsque de nouvelles fonctionnalités apparaissent pendant le projet.

Définir le résultat attendu

Un résultat utile est vérifiable sans promettre un chiffre que personne ne peut encore mesurer. Il peut s’agir d’un parcours complet, d’un export exploitable, d’une intégration fiable, d’une mise en production documentée ou d’un temps de traitement que l’équipe pourra suivre après le lancement.

  • Le résultat attendu pour l’utilisateur ou l’équipe métier
  • La preuve observable que le périmètre est terminé
  • Les indicateurs qui seront mesurés après la mise en ligne
  • Ce qui est explicitement hors périmètre

Cartographier les utilisateurs et les contraintes

Listez les publics concernés, leurs droits, leurs données et leurs situations d’échec. Ajoutez les contraintes qui changent réellement la solution : systèmes existants, exigences de sécurité, accessibilité, disponibilité, données personnelles, langues, appareils et processus de validation.

Cette étape évite de comparer des devis qui ne couvrent pas le même produit. Elle permet aussi de repérer tôt les dépendances qui peuvent modifier le calendrier.

Choisir le bon niveau de détail

Avant un premier cadrage, une page peut suffire si le besoin est simple. Pour une plateforme, un logiciel métier ou une reprise de produit, il faut au minimum les parcours principaux, les rôles, les intégrations connues et les règles métier critiques.

L’objectif n’est pas de figer toute l’interface avant d’avoir compris le problème. C’est de donner assez de contexte pour que les hypothèses, les exclusions et les risques soient comparables.

Demander un devis comparable

Demandez à chaque partenaire de séparer le cadrage, la conception, le développement, la mise en production et le suivi. Un montant global sans hypothèses ne permet pas de comprendre ce qui est inclus ni ce qui déclenchera un changement.

Le document devrait préciser les livrables, les responsabilités, les dépendances, les validations, les conditions de transfert et les éléments qui font varier le budget. Le prix est alors une conséquence d’un périmètre explicite, pas une promesse isolée.

La checklist de départ

Avant d’envoyer une demande, réunissez ces éléments dans un document court. Il peut évoluer pendant le cadrage, mais il doit rendre les décisions visibles.

  • Problème, contexte et objectif métier
  • Publics, parcours principaux et cas d’échec
  • Systèmes, données et accès déjà disponibles
  • Contraintes de sécurité, conformité, accessibilité et performance
  • Livrables attendus et exclusions
  • Échéance motivée par un événement réel
  • Fourchette budgétaire ou mode de décision
  • Personnes habilitées à valider

Sources