---
title: "Faut-il répondre si une fonction produit reste à livrer?"
description: "Vérifiez la date d’exigibilité, la version offerte, le chemin de livraison, la recette et les pouvoirs avant de citer la roadmap."
canonical: "https://zephior.com/fr/insights/qualify-a-bid-with-a-product-roadmap-dependency"
last-updated: 2026-09-03
---

# Faut-il répondre si une fonction produit reste à livrer?

> Vérifiez la date d’exigibilité, la version offerte, le chemin de livraison, la recette et les pouvoirs avant de citer la roadmap.

Par [Tony Kim](https://zephior.com/fr/authors/tony-kim). Publié le 2026-09-03; mis à jour le 2026-09-03. 17 min de lecture.

## Définition

La `roadmap_dependency_decision` décide si une exigence peut être portée par une offre alors que la version proposée ne possède pas encore la fonction vérifiée. Elle fixe la consultation, le lot, le candidat, l’édition logicielle et le mode de déploiement. Elle rattache ensuite le texte qui commande, son traitement dans l’évaluation et sa date d’exigibilité au produit actuel, au statut prouvé du changement, à la chaîne de mise en production, au scénario de recette, aux solutions autorisées et aux pouvoirs d’engagement. Elle conserve aussi le prix, les clauses touchées, les éléments contraires et la date de péremption. Ce dossier ne transforme ni une intention ni un prototype en promesse. Il ne décide pas la priorité produit, n’engage aucun budget, ne sollicite pas l’acheteur et ne dépose pas l’offre.

## Problème

Une roadmap est faite pour arbitrer un produit, pas pour décrire seule une obligation client. Sa date peut représenter le début des travaux, une fenêtre visée, une bêta ou une mise à disposition générale. Le périmètre peut encore exclure la langue, l’hébergement ou la charge demandée par l’acheteur. La consultation ajoute sa propre horloge. Certaines cases exigent une capacité au jour du dépôt ou lors d’une démonstration. D’autres demandent une livraison pendant le projet et la contrôlent à la recette. Une réponse qui efface ces différences peut déclarer disponible ce qui ne l’est pas, ou écarter une offre alors que le délai contractuel permet une livraison maîtrisée.

## Point de vue

Partez de l’événement où l’acheteur doit constater le résultat. Établissez ensuite une photographie testée de la version, de l’édition et du déploiement offerts. La différence résiduelle peut relever d’un paramétrage, d’une intégration, d’un travail de projet ou d’une modification du produit. Seul ce dernier cas appelle une analyse de roadmap. Une décision favorable exige un périmètre approuvé, des moyens réservés, des dépendances datées, des contrôles de sortie adaptés, une recette définie et une formulation acceptée par les détenteurs du pouvoir commercial et contractuel. L’agent prépare la preuve et sait s’abstenir. Il ne s’approprie jamais le pouvoir de promettre.

## La date utile est celle où l’acheteur attend le résultat

Rapprochez la ligne fonctionnelle de toutes les pièces qui lui donnent un effet. Le cadre de réponse peut exiger une réponse au présent, le règlement attribuer des points à la méthode, le scénario de soutenance demander une démonstration et le cahier de recette placer le contrôle six mois après notification. Le projet de contrat peut encore transformer cette date en obligation assortie de pénalités. Enregistrez séparément l’événement de capacité et l’événement de preuve. L’envoi d’un plan aujourd’hui ne signifie pas que le produit doit être disponible aujourd’hui, sauf si le texte l’impose.

Le Code de la commande publique donne deux repères, sans remplacer l’analyse du dossier. L’article L2152-2 qualifie d’irrégulière une offre qui ne respecte pas les exigences des documents de la consultation, notamment lorsqu’elle est incomplète. L’article R2152-7, dans sa version en vigueur depuis le 21 août 2026 pour les consultations visées par sa règle transitoire, autorise des critères liés à l’objet ou aux conditions d’exécution, dont la valeur technique, les caractéristiques fonctionnelles, l’interopérabilité et les délais. Pour une consultation plus ancienne, vérifiez la version applicable. Le classement juridique et la rédaction propre au marché commandent le traitement de la fonction future.

Classez la ligne: condition sans laquelle l’offre est irrégulière, élément de démonstration, critère noté, variante, engagement de mise en œuvre, recette ou obligation récurrente. Une qualification glissée dans un commentaire ne crée pas une variante si le règlement ne l’autorise pas. Une fonction livrable après attribution ne devient pas pour autant acceptable dans une case exigeant la disponibilité au dépôt. Si les pièces actuelles se contredisent, choisissez `source_conflict`. Une conséquence de droit non résolue reçoit `legal_review_required` et, si le calendrier le permet, une question par le canal officiel.

**Deux horloges pour la même fonction**

| Jalon | Question de contrôle | Pièce utile |
| --- | --- | --- |
| Dépôt | La version offerte doit-elle déjà exécuter la fonction? | Instruction de réponse et test actuel |
| Soutenance | Quel comportement sera observé ou simulé? | Scénario, environnement et règles de démonstration |
| Attribution ou signature | Quel texte devient opposable? | Offre finale, échanges et annexes contractuelles |
| Recette | Quel résultat mesurable déclenche l’acceptation? | Cas, données, seuils, délai et traitement de l’échec |
| Mise en service | Quand faut-il exploiter et supporter la fonction? | Planning, volumétrie et conditions opérationnelles |

## Testez l’offre exacte avant d’ouvrir la roadmap

Le nom commercial du produit décrit un ensemble trop large. Indiquez l’édition, la version, la région, la langue, le modèle d’hébergement, les modules sous licence, la configuration du tenant, les appareils et les services tiers. Reproduisez la tâche demandée avec des données représentatives. La preuve retient les entrées, le résultat, l’environnement, les limites, la date et le responsable. Une page d’aide non versionnée peut orienter le test; elle ne tranche pas une différence entre éditions ou déploiements.

Attribuez ensuite une nature à l’écart. `available_verified` constate que la fonction existe dans le périmètre offert. `configuration_required` repose sur un réglage supporté. `existing_integration_required` appelle une interface déjà publiée et maintenue. `custom_delivery_work` correspond à une réalisation limitée au marché. `product_change_required` modifie le comportement réutilisable du produit. Ce vocabulaire empêche de faire financer un paramétrage par la roadmap ou, à l’inverse, de cacher une évolution de plateforme dans le forfait d’intégration.

Pour le changement produit, remplacez l’étiquette vague par un état prouvé: `idea_recorded`, `discovery_active`, `solution_approved`, `funded_unscheduled`, `release_scheduled`, `in_development`, `release_candidate`, `limited_availability` ou `generally_available`. La définition interne de chaque état doit indiquer qui le prononce et sur quelle preuve. Un périmètre validé ne réserve pas les développeurs. Une version candidate n’engage pas une diffusion. Une disponibilité limitée peut exclure le pays, le volume ou le support promis dans l’offre.

**Lecture factuelle des états produit**

| État | Ce que la preuve établit | Ce qui reste ouvert |
| --- | --- | --- |
| Idée ou étude | Le besoin est enregistré et étudié | Solution, priorité et date |
| Solution approuvée | Le périmètre et l’approche sont acceptés | Budget et capacité affectée |
| Financé et planifié | Une fenêtre et des moyens sont attribués | Construction, contrôle et diffusion réussis |
| En développement | La réalisation du périmètre a commencé | Qualité, livraison et disponibilité client |
| Candidat à la diffusion | Les contrôles internes nommés sont franchis | Autorisation de production et recette acheteur |
| Disponible généralement | Le périmètre publié est exploitable et supporté | Conformité à tout contexte contractuel |

## Le chemin se termine à la recette, pas à la compilation

Écrivez d’abord le dernier essai que l’acheteur devra accepter, puis remontez. Avant lui se trouvent parfois l’ouverture d’un environnement, le chargement des données, l’intégration, la formation et l’autorisation de production. Avant la diffusion produit viennent la conception, le développement, les jeux d’essai, la performance, la sécurité, la protection des données, l’accessibilité, la traduction, la documentation, l’exploitation et le support. Retenez les étapes nécessaires à ce cas précis et nommez la fonction qui les commande.

Un jalon possède des préalables, un propriétaire, une date au plus tôt, une date au plus tard et une preuve de clôture. Ajoutez un chemin défavorable pour l’échec d’un test, le retard d’un fournisseur ou l’arrivée tardive des données client. Une ressource partagée entre deux engagements figure elle aussi dans le graphe. La date à comparer au marché est la fin du chemin obligatoire le plus tardif, marge approuvée comprise. Le calendrier produit le plus favorable reste visible, mais il ne commande pas la décision.

La preuve de sortie varie avec le risque. NIST SP 800-218 fournit des pratiques de développement logiciel sécurisé intégrables au cycle de vie. Ce document ne certifie ni la maturité générale du produit ni la conformité au besoin de l’acheteur. Il aide à rendre explicites les activités et preuves de sécurité applicables. Ajoutez les contrôles fonctionnels, de charge, d’accessibilité et d’exploitation nécessaires. Fixer ces preuves avant la promesse permet de savoir ce que signifie réellement « livré ».

**Contenu minimal d’un jalon**

| Champ | Valeur attendue | Effet sur la décision |
| --- | --- | --- |
| Responsable | Personne ou fonction comptable du résultat | Identifie la source de confirmation |
| Préalables | Étapes qui doivent être closes auparavant | Révèle le chemin critique |
| Fourchette | Dates au plus tôt et au plus tard justifiées | Conserve l’incertitude temporelle |
| Preuve de fin | Essai, décision, diffusion ou procès-verbal | Définit le passage à l’état suivant |
| Branche défavorable | Retard, défaut ou perte d’une dépendance | Associe le risque à sa conséquence |
| Péremption | Fait qui invalide le calcul | Impose une nouvelle analyse |

## Validez la phrase avec le prix, la recette et le contrat

Le texte externe vient après le dossier de preuve. « Fonction étudiée », « cible du produit », « fonction proposée » et « livraison garantie au 30 juin » n’ont ni le même sens ni la même exposition. Une matrice binaire ne permet pas de qualifier discrètement un oui. Utilisez le champ prévu pour une explication, une variante ou une réserve lorsque le règlement l’autorise. Placez la précision là où elle sera effectivement évaluée et vérifiez qu’elle ne contredit pas une exigence sans réserve.

Chaque pouvoir couvre une partie. Le produit décide du périmètre réutilisable et de sa priorité. L’ingénierie confirme architecture, capacité et contrôles de sortie. Le projet porte les actions propres au client. La direction commerciale accepte le coût et l’effet sur les autres engagements. Sécurité, données ou conformité valident leur domaine. Le juridique examine la formulation, la garantie, les recours, la propriété intellectuelle et le mécanisme d’écart. Conservez la version exacte soumise à chacun. Une approbation générale du dossier ne doit pas masquer une phrase ajoutée ensuite.

Cherchez aussi une voie qui évite le développement. Un réglage pris en charge peut atteindre le résultat. Une intégration existante peut assurer le comportement avec un partage clair des responsabilités. Une variante, une phase ou une solution équivalente peut être expressément recevable. Une question peut préciser le jalon ou le résultat attendu sans divulguer des informations produit sensibles. Chacune de ces voies possède sa propre base dans les documents, sa preuve, son prix et sa recette. L’absence de réponse de l’acheteur n’autorise rien de nouveau.

**Niveaux de langage produit dans une offre**

| Position | Fondement minimal | Limite à conserver |
| --- | --- | --- |
| Capacité actuelle | Essai de la version et du périmètre offerts | Décrire le comportement observé seulement |
| Intention produit | Divulgation non contractuelle approuvée | Ne pas suggérer une disponibilité promise |
| Engagement futur | Périmètre, chemin, date, prix et recette approuvés | Employer uniquement le texte autorisé |
| Solution permise | Base procédurale et réponse alternative complète | Montrer les différences à l’évaluateur |
| Obligation contractuelle | Annexe, dépendances, garantie et recours validés | Aligner toutes les pièces de l’offre |

## Exemple: la désactivation automatique dépend encore du client

Une université fictive achète une plateforme de gestion de la recherche. Les offres sont dues le 7 décembre 2026, une soutenance a lieu en janvier et la recette finale est fixée au 30 juin 2027. Le produit doit retirer l’accès d’un collaborateur moins de dix minutes après la désactivation dans l’annuaire RH, puis conserver la trace horodatée de l’opération. La soutenance note le plan d’intégration; la fonction sera testée seulement à la recette. Cette situation et ces dates ne viennent d’aucune consultation réelle.

La version offerte sait créer et modifier les comptes par import SCIM, mais la suppression automatique utilise encore un traitement nocturne. Un service d’événements est `release_scheduled` pour mars 2027, avec équipe affectée. Son comportement dépend toutefois du connecteur de l’annuaire choisi par l’université, dont la spécification d’événements n’est pas fournie. Le test de conservation des journaux n’a pas encore été conçu pour la durée contractuelle. Le chemin favorable finit en mai; l’hypothèse de reprise après défaut du connecteur dépasse juin. Le résultat est `roadmap_dependency_unresolved`, jusqu’à obtention de la spécification, définition de la preuve de journalisation et validation d’un repli conforme.

La sortie structurée garde identifiants de consultation et de lot, versions sources, empreintes candidat et produit, exigence, effet de notation, événements de capacité et de preuve, essais actuels, état produit, graphe de dépendances, fourchettes, recette, solutions, effets économiques et contractuels, phrase proposée, validations, contre-preuves, prochaine action et péremption. Les états finaux sont `bid_on_current_capability`, `bid_with_approved_product_commitment`, `bid_with_permitted_alternative`, `clarification_required`, `roadmap_dependency_unresolved`, `no_bid_dependency`, `source_conflict`, `legal_review_required` et `authority_missing`. Un agent peut rechercher les clauses, rapprocher les preuves produit, calculer les chemins, contrôler les incohérences et préparer une recommandation ou une question autorisée. Il s’arrête avant changement de priorité, allocation, divulgation, promesse, acceptation d’écart, contact et dépôt.

## Résultats utiles

- La consultation, le lot, le candidat, l’édition, le déploiement et l’heure de contrôle forment un périmètre immuable.
- Chaque exigence dépendante de la roadmap conserve sa source, sa version, son effet d’évaluation et son jalon d’exigibilité.
- Le comportement actuel est testé séparément du paramétrage, de l’intégration, du projet spécifique et du développement produit.
- Idée, étude, solution approuvée, financement, planification, développement, candidat à la diffusion et disponibilité générale sont des états différents.
- Chaque dépendance de livraison indique son responsable, ses préalables, sa fourchette, sa preuve de fin et son scénario défavorable.
- Le calendrier inclut les contrôles de sécurité, de données, d’accessibilité, d’exploitation et de support applicables.
- La recette mesure le résultat demandé par l’acheteur plutôt que la seule présence du code.
- Une variante, une solution équivalente, une réserve ou une question respecte le mécanisme autorisé par la consultation.
- La même promesse approuvée se retrouve dans le mémoire, le prix, le planning, le service et le contrat.
- Aucun agent ne déplace une priorité, ne révèle une roadmap confidentielle, ne promet une date ou ne soumet sans mandat distinct.

## Déroulement

1. **Verrouiller le périmètre.** Consignez l’acheteur, la procédure, le lot, le candidat, l’édition offerte, le déploiement, les versions documentaires et l’instant du contrôle.
2. **Identifier le jalon qui commande.** Relevez la phrase exacte, son caractère éliminatoire ou noté, la preuve attendue et l’événement où la capacité doit exister.
3. **Tester le produit proposé.** Exécutez le comportement sur la bonne version et gardez configuration, conditions, limites, résultat, date et propriétaire de la preuve.
4. **Qualifier la différence.** Distinguez réglage, interface existante, réalisation propre au projet et changement réutilisable du produit, puis prouvez son état interne.
5. **Construire la chaîne de disponibilité.** Remontez depuis la recette vers le déploiement, la diffusion, les contrôles, la construction, la conception et les décisions produit.
6. **Comparer les voies recevables.** Testez séparément la capacité courante, le paramétrage, l’intégration, la variante, la solution alternative, la réserve et l’engagement futur.
7. **Propager les conséquences.** Réconciliez la dépendance avec charge, prix, calendrier, recette, garantie, niveaux de service, recours et réponses connexes.
8. **Faire approuver les mots.** Soumettez la phrase destinée à l’acheteur et son exposition aux autorités produit, technique, projet, commerciale et juridique requises.
9. **Périmer au changement.** Réouvrez la décision après modificatif, réduction de portée, retard, essai manqué, conflit de capacité, dépendance perdue ou nouvelle clause.

## Décisions clés

- Quel comportement observable l’exigence impose-t-elle exactement?
- S’agit-il d’une condition de régularité, d’une démonstration, d’un critère noté, d’un livrable, d’une recette ou d’une obligation de service?
- À quel événement le comportement doit-il exister et à quelle date sa preuve doit-elle être remise?
- Que démontre aujourd’hui la combinaison exacte d’édition, de version, de région et de déploiement proposée?
- Un paramétrage supporté, une interface publiée ou une solution admise évite-t-il de modifier le produit?
- Quel état de cycle de vie est prouvé pour la fonction future, par quelle source datée et quel responsable?
- Quelles décisions, équipes, vérifications, parties externes et actions client gouvernent le chemin le plus tardif?
- Quel scénario de recette prouvera le résultat, sa charge, ses erreurs et ses conditions limites?
- Quels effets apparaissent dans le prix, le projet, la garantie, le service, les recours et les autres engagements?
- Quelle formulation peut être tenue aujourd’hui, et qui possède le pouvoir de l’autoriser?
- Quelle date ou quel événement ferme la voie et déclenche un arrêt?

## Risques

- Un trimestre indicatif devient une date contractuelle dans la réponse.
- Une maquette, un environnement de test ou une fonction sous drapeau est annoncé comme produit disponible.
- La preuve concerne une autre édition, une autre région ou un hébergement absent de l’offre.
- La faisabilité technique est confondue avec la priorité, le financement et la capacité approuvés.
- Le calendrier s’arrête à la fin du code et omet assurance, documentation, déploiement, support ou recette.
- La fonction doit être démontrée pendant l’évaluation alors que le plan la place seulement avant le démarrage du service.
- Un contournement modifie le résultat demandé sans passer par une variante ou une réserve autorisée.
- Le mémoire technique engage une date que le prix, le plan de projet ou le contrat ne financent pas.
- Deux offres réservent implicitement la même équipe produit sur des périodes incompatibles.
- Des détails de roadmap, des failles, du code ou des informations client sont transmis sans droit à un agent ou à l’acheteur.

## Indicateurs

- exigences futures reliées à une source, un effet d’évaluation et un événement d’exigibilité
- états actuels prouvés pour l’édition, la version, le déploiement et les conditions proposés
- éléments de roadmap associés à un état de cycle de vie défini et documenté
- jalons avec responsable, préalables, dates au plus tôt et au plus tard et preuve de clôture
- engagements futurs dont la recette était fixée avant leur approbation
- dépendances réconciliées entre mémoire, prix, projet et contrat
- décisions conditionnelles réexaminées avant ou au moment de leur péremption
- décisions favorables signées par les pouvoirs produit et commerciaux nommés
- promesses sans preuve, changements de priorité et dépôts non autorisés; cible zéro

## Questions fréquentes

### Une fonction planifiée permet-elle de cocher oui dans un RFP?

Pas à elle seule. Le oui doit rester exact selon les instructions. Prouvez le statut, la date d’exigibilité, le chemin complet, la recette, les conséquences et l’autorité qui porte la promesse.

### Peut-on candidater lorsque la fonction est exigée à la mise en service?

Oui si les documents permettent cette livraison future et si le scénario au plus tard atteint la mise en service avec des preuves, des moyens et des validations suffisants. Toutes les pièces doivent porter la même hypothèse.

### Une bêta clôt-elle la dépendance de roadmap?

Non par principe. Vérifiez ses restrictions, son support, son déploiement, les contrôles restants et le test demandé par l’acheteur. La dépendance se ferme à l’état précis qui a été promis.

### Faut-il révéler toute la roadmap à l’acheteur?

Non. Communiquez seulement les faits nécessaires et approuvés pour une réponse exacte. Protégez les détails confidentiels, tout en rendant visible toute dépendance qui modifie la conformité ou l’engagement offert.

### Un agent d’IA peut-il promettre la date de livraison?

Non. Il peut produire le dossier cité, calculer les dates et signaler les lacunes. Les détenteurs humains des pouvoirs produit, projet, commerciaux et juridiques approuvent la phrase et l’action extérieure.


## Sources primaires

- [Code de la commande publique, article L2152-2](https://www.legifrance.gouv.fr/loda/article_lc/LEGIARTI000037703649), Légifrance
- [Code de la commande publique, article R2152-7, version du 21 août 2026](https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000045739587/2026-08-21/), Légifrance
- [Directive 2014/24/UE, texte consolidé, articles 42, 56, 67 et 70](https://eur-lex.europa.eu/eli/dir/2014/24/2026-01-01/fra), EUR-Lex
- [NIST Secure Software Development Framework, version 1.1](https://csrc.nist.gov/pubs/sp/800/218/final), National Institute of Standards and Technology


## Articles complémentaires

- [Peut-on candidater si le certificat requis tarde?](https://zephior.com/fr/insights/decide-whether-to-bid-with-missing-certification)
- [Faut-il candidater sans satisfaire toutes les exigences?](https://zephior.com/fr/insights/decide-whether-a-partial-capability-fit-is-biddable)
- [Avis publié, mais le dossier est-il accessible ?](https://zephior.com/fr/insights/distinguish-notice-publication-from-document-release)
- [Que faire si questions et critères ne concordent pas ?](https://zephior.com/fr/insights/resolve-conflict-between-criteria-and-rfp-questions)