Chaque format doit répondre à une question différente. Choisir l’étape adaptée évite de payer une démonstration quand l’entreprise attend un service exploitable.
Les mots sont parfois utilisés comme des arguments commerciaux alors qu’ils devraient décrire un objectif, un niveau d’usage et une décision de fin. Demandez au prestataire ce qui sera réellement utilisable, connecté, sécurisé et maintenu.
Pour chaque proposition, faites compléter cette phrase : « À la fin de cette mission, nous disposerons de … et nous pourrons décider de … ».
Les durées et les budgets ne sont pas généralisables sans connaître le périmètre, les données, les intégrations et le niveau de production. Le tableau décrit donc les responsabilités à clarifier.
| Critère | Objectif | Livrable | Niveau de risque | Données | Utilisateurs | Intégration SI | Durée | Décision obtenue |
|---|---|---|---|---|---|---|---|---|
| Audit | Comprendre la situation, les opportunités et les contraintes. | Diagnostic, risques, priorités et recommandations. | Faible engagement de réalisation. | Inventaire, échantillons et entretiens selon le sujet. | Décideurs, métiers, données, IT et sécurité selon le périmètre. | Analyse des dépendances, sans intégration nécessaire. | Phase ponctuelle, adaptée à la profondeur de l’analyse. | Décider quoi approfondir, dans quel ordre et sous quelles conditions. |
| Cadrage | Transformer une priorité en mission consultable. | Périmètre, hypothèses, architecture cible, critères et gouvernance. | Engagement limité, mais choix structurants possibles. | Échantillons représentatifs et règles d’accès à préciser. | Sponsor, utilisateurs, responsable produit ou métier, IT. | Interfaces et contraintes décrites avant réalisation. | Jusqu’à ce que le périmètre et la décision de test soient assez clairs. | Lancer un test, consulter des prestataires, revoir le besoin ou arrêter. |
| POC | Vérifier une hypothèse technique ou de faisabilité. | Résultat de test, limites, mesures et recommandation. | Maîtrisé si l’hypothèse et la fin du test sont définies. | Échantillon représentatif, parfois préparé pour le test. | Équipe projet et experts, avec quelques utilisateurs si nécessaire. | Souvent limitée ou simulée. | Courte phase de preuve, bornée par une question précise. | Confirmer, invalider ou reformuler l’hypothèse. |
| Prototype | Rendre l’idée manipulable et tester le parcours. | Interface ou workflow démontrable, non destiné à l’exploitation. | Risque de confusion avec un produit fini. | Données d’exemple ou jeu limité, clairement signalé. | Utilisateurs pilotes pour retours qualitatifs. | Partielle, simulée ou absente. | Limitée au niveau de fidélité nécessaire pour apprendre. | Revoir l’usage, préciser les besoins ou préparer un MVP. |
| MVP | Fournir le plus petit service utilisable dans un cadre défini. | Produit limité, testé avec de vrais utilisateurs et suivi. | Plus élevé car l’usage devient réel. | Données réelles avec règles de qualité, accès et protection. | Groupe d’utilisateurs identifié, avec support et retours organisés. | Les intégrations indispensables sont opérationnelles. | Dépend du périmètre minimal réellement exploitable. | Améliorer, élargir, maintenir le périmètre ou arrêter. |
| Pilote | Tester le service en conditions limitées d’organisation. | Service déployé sur une population ou un périmètre contrôlé. | Proche de la production sur la zone pilote. | Données réelles, volumes et incidents observables. | Population pilote accompagnée, sponsor et équipe de support. | Réelle sur le périmètre pilote. | Assez longue pour observer l’usage et les situations d’exception. | Généraliser, corriger, prolonger ou arrêter. |
| Production | Rendre le service fiable, sécurisé et exploitable au quotidien. | Service déployé, supervisé, documenté et supporté. | Élevé car les utilisateurs et processus dépendent du service. | Données réelles, gouvernées, journalisées et protégées. | Population cible, support, exploitation et responsables métier. | Complète selon l’architecture et les règles du SI. | Cycle de livraison suivi d’une exploitation continue. | Accepter le service et organiser son évolution. |
| Industrialisation | Faire tenir le service dans la durée et à plus grande échelle. | Monitoring renforcé, procédures, capacité, maintenance et amélioration. | Risque opérationnel, financier et de dépendance à contrôler. | Flux réels, dérives, qualité et coûts suivis dans le temps. | Ensemble des utilisateurs, exploitation et gouvernance. | Durcie, automatisée et documentée. | Activité continue, rythmée par les évolutions et incidents. | Maintenir, optimiser, étendre, remplacer ou retirer. |
L’audit décrit l’existant et les options. Le cadrage transforme une option en périmètre consultable : utilisateurs, données, intégrations, risques, critères de réussite et responsabilités.
À la fin, vous devez savoir quelle décision prendre et quelles inconnues restent à tester.
Le POC répond à une question précise de faisabilité. Il ne doit pas accumuler des fonctionnalités. Les données et le protocole doivent être assez représentatifs pour que la conclusion soit utile.
À la fin, l’hypothèse est confirmée, infirmée ou reformulée.
Le prototype sert à apprendre sur le parcours, l’interface ou l’enchaînement des tâches. Il peut utiliser des simplifications qui seraient inacceptables en exploitation.
À la fin, les retours utilisateurs permettent de revoir l’usage ou de préparer un périmètre utilisable.
Le MVP fournit un service limité mais utilisable. Il implique de vrais utilisateurs, des données réelles, une responsabilité de support et des critères de qualité adaptés au périmètre.
À la fin, vous savez si le service mérite d’être amélioré, élargi ou arrêté.
Le pilote teste le service dans une partie de l’organisation. Il doit exposer les situations réelles : charge, exceptions, adoption, support, erreurs et impacts sur les processus.
À la fin, vous disposez d’éléments pour décider d’une généralisation ou d’une reprise.
La production exige sécurité, supervision, gestion des accès, procédure d’incident, documentation, critères de service et responsabilité d’exploitation.
À la fin, le service est accepté par les responsables métier et techniques, avec un mode d’exploitation défini.
L’industrialisation traite la capacité, la fiabilité, les coûts, les mises à jour, les dérives et la continuité. La maintenance doit couvrir les changements de données, d’outils, de modèles et d’usage.
À la fin de chaque cycle, l’organisation décide de maintenir, améliorer, étendre, remplacer ou retirer le service.
Le test produit une démonstration, mais aucun critère ne dit quoi faire du résultat.
Les simplifications de données, de sécurité ou d’intégration restent cachées.
Le service est livré sans population identifiée, support ni boucle de retour.
Les erreurs, coûts, dérives et incidents ne sont pas détectés ni attribués.
Les changements de données, d’outils et de processus apparaissent après la livraison.
Le périmètre, la population ou la durée d’observation restent ouverts, ce qui empêche la décision.
Pour aligner le périmètre et les postes de coût, rapprochez ce guide du budget d’un projet IA en PME et du guide des prix d’une agence IA.
Les réponses doivent faire apparaître les simplifications de l’étape et les travaux nécessaires avant un usage réel.
Un consultant est souvent utile avant la réalisation, une agence pour construire et tester, et un intégrateur lorsque la production dépend fortement du SI. Comparez les responsabilités réelles.
Pour concevoir et livrer un cas d’usage avec une équipe projet.
Pour auditer, prioriser, cadrer et accompagner une décision.
Pour connecter, sécuriser et exploiter une solution dans le SI.
Décrivez la décision attendue, les données disponibles, les utilisateurs et les intégrations. Ces éléments permettent d’orienter la recherche vers les profils adaptés.