Aller au contenu principal

TEMPLATE

Template RFP Cloud : le cahier des charges type

Le modèle complet pour structurer votre appel d'offres cloud : critères techniques, grille d'évaluation et pièges à éviter.

Recevez le template RFP Cloud en PDF

Entrez votre email pour recevoir ce template avec la grille d'évaluation et 3 exemples de RFP.

Pourquoi un RFP structuré est indispensable

Un appel d'offres cloud mal structuré conduit à des réponses incomparables, des coûts cachés et des engagements inadaptés. Le résultat : un projet de migration qui dérape en coûts et en délais, ou pire, un lock-in technologique qui pèsera pendant des années.

Ce template vous donne la structure complète d'un RFP cloud professionnel, les critères techniques à ne pas oublier, une grille d'évaluation pondérée et les pièges classiques à éviter. Il est issu de dizaines de consultations que nous avons accompagnées pour des ETI et grands comptes.

Adaptez ce template à votre contexte : tous les critères ne sont pas pertinents pour tous les projets. L'essentiel est de poser les bonnes questions pour obtenir des réponses comparables et prendre une décision éclairée.

1. Structure type d'un RFP Cloud

Un RFP cloud complet se structure en 8 sections. Chaque section doit être suffisamment précise pour obtenir des réponses comparables entre les fournisseurs, sans être si restrictive qu'elle élimine des solutions pertinentes.

1. Contexte et objectifs

Présentez votre entreprise, votre SI actuel, les motivations de la migration cloud (agilité, coûts, scalabilité, conformité) et les objectifs mesurables attendus. Plus le contexte est clair, plus les réponses seront pertinentes. Incluez les contraintes calendaires et budgétaires.

2. Périmètre applicatif

Listez les applications et workloads concernés avec leurs caractéristiques : volumétrie, criticité, dépendances, technologies utilisées. Précisez ce qui est inclus et exclu du périmètre. Fournissez un inventaire technique si possible (nombre de serveurs, bases de données, stockage).

3. Exigences techniques

Spécifiez vos besoins en compute, storage, networking, containers, services managés. Distinguez les exigences obligatoires (must-have) des souhaitées (nice-to-have). Précisez les contraintes de localisation des données (souveraineté), de performance (latence, IOPS) et de disponibilité.

4. Niveaux de service (SLA)

Définissez vos attentes en termes de disponibilité (99,9 % ? 99,99 % ?), de RTO/RPO, de temps de réponse du support, et de pénalités en cas de non-respect. Demandez les SLA réels (pas marketing) et les historiques d'incidents des 12 derniers mois.

5. Sécurité et conformité

Précisez vos exigences de sécurité : certifications requises (ISO 27001, SOC 2, HDS, SecNumCloud), chiffrement, gestion des identités, journalisation, conformité réglementaire (RGPD, NIS2). Demandez les rapports d'audit et les certifications en vigueur.

6. Plan de migration

Demandez une proposition de plan de migration détaillé : méthodologie, phasage, outillage, gestion des risques, stratégie de rollback. Précisez vos contraintes (fenêtres de maintenance, indisponibilité maximale acceptable, migration en parallèle ou cut-over).

7. Modèle de pricing

Demandez un chiffrage détaillé sur 3 ans avec les hypothèses de volumétrie. Exigez la transparence sur tous les postes de coûts : compute, stockage, réseau (egress !), support, licences, services professionnels. Demandez un TCO comparatif et les mécanismes de contrôle des coûts.

8. Critères d'évaluation

Communiquez aux fournisseurs les critères et la pondération que vous utiliserez pour évaluer les réponses. Cette transparence améliore la qualité des réponses et renforce l'équité du processus.

2. Les critères techniques essentiels

Compute & Containers

  • Gamme d'instances (CPU, GPU, mémoire, bare metal)
  • Kubernetes managé (version, conformité CNCF)
  • Serverless (fonctions, containers, limitations)
  • Auto-scaling (réactivité, granularité)

Storage & Data

  • Types de stockage (bloc, objet, fichier, archive)
  • Performances (IOPS, throughput, latence)
  • Bases de données managées (relationnelles, NoSQL)
  • Services data (ETL, streaming, data warehouse)

Networking & Observabilité

  • Connectivité hybride (VPN, Direct Connect, peering)
  • CDN, DNS, load balancing, WAF
  • Monitoring, logging, tracing natifs
  • Intégration avec outils tiers (Datadog, Grafana)

IAM & Conformité

  • Gestion des identités (SSO, SAML, OIDC)
  • RBAC, policies, service accounts
  • Certifications et attestations de conformité
  • Localisation des données et souveraineté

3. Grille d'évaluation pondérée

Cette grille type attribue un poids à chaque famille de critères. Adaptez les pondérations à vos priorités. Chaque critère est noté de 1 (insuffisant) à 5 (excellent). Le score final est la somme pondérée des notes.

Critère Poids Ce qu'on évalue
Adéquation technique 25 % Couverture des exigences fonctionnelles et techniques, maturité des services
Sécurité & Conformité 20 % Certifications, chiffrement, IAM, conformité réglementaire, transparence
Coût total (TCO 3 ans) 20 % Coûts directs, indirects, prévisibilité, mécanismes de contrôle
Plan de migration 15 % Méthodologie, phasage, gestion des risques, expérience documentée
Support & SLA 10 % Niveaux de support, temps de réponse, SLA de disponibilité, pénalités
Réversibilité 10 % Portabilité des données, standards ouverts, clause de sortie, assistance à la migration sortante

4. Les pièges à éviter

Le lock-in technologique

Chaque service propriétaire utilisé augmente votre coût de sortie. Évaluez systématiquement l'alternative open source ou multi-cloud pour chaque service managé. Ce n'est pas une raison pour tout refuser, mais pour décider en connaissance de cause. Exigez une clause de réversibilité dans le contrat avec un engagement d'assistance à la migration sortante.

Les coûts cachés

Les frais d'egress (sortie de données) peuvent représenter 10 à 20 % de la facture cloud et sont rarement mis en avant dans les propositions commerciales. Les coûts de support premium, les licences de services avancés (observabilité, sécurité), et les frais de transfert inter-régions sont d'autres postes souvent sous-estimés. Exigez un TCO détaillé sur 3 ans avec tous les postes de coûts.

Les SLA ambigus

Un SLA de 99,99 % ne signifie rien si le périmètre de mesure n'est pas clair. Le SLA couvre-t-il le service dans une seule zone de disponibilité ou en multi-AZ ? Les maintenances planifiées sont-elles exclues ? Les pénalités sont-elles des crédits cloud (qui vous lient davantage) ou des remboursements réels ? Exigez des définitions précises et des historiques d'incidents.

L'absence de clause de réversibilité

Sans clause de réversibilité contractuelle, vous êtes prisonnier de votre fournisseur. La clause doit définir : le format d'export des données, le délai de mise à disposition, l'assistance technique à la migration sortante, et la durée de conservation des données après résiliation. Négociez cette clause avant la signature, pas au moment de la sortie.

5. Exemple : RFP pour une migration AWS vers multi-cloud

ETI industrielle — 300 collaborateurs — 40 applications — Infrastructure 100 % AWS

Contexte

Après 5 ans sur AWS, l'entreprise souhaite évaluer une stratégie multi-cloud pour réduire sa dépendance à un seul fournisseur, optimiser ses coûts et répondre aux exigences de souveraineté de certains clients industriels (SecNumCloud). Le périmètre couvre 40 applications dont 12 critiques, 15 bases de données, et 200 To de stockage.

Points clés du RFP

  • + Exigence d'une approche Kubernetes-native pour la portabilité des workloads.
  • + Demande de chiffrage séparé par workload pour permettre un placement optimal.
  • + Critère de souveraineté pondéré à 15 % pour les applications manipulant des données industrielles sensibles.
  • + Clause de réversibilité avec export des données sous 30 jours en format standard.
  • + Demande de POC sur 2 applications pilotes avant engagement.

Résultat

Le RFP structuré a permis de recevoir 4 réponses comparables, d'identifier le meilleur rapport qualité-prix et de négocier des conditions contractuelles solides. La migration des 2 applications pilotes a validé la faisabilité technique avant l'engagement sur le périmètre complet.

Besoin d'aide pour structurer votre appel d'offres cloud ?