IaaS, PaaS, SaaS
Le bon niveau dépend du contrôle requis, des compétences disponibles, de la criticité, du coût et du rythme de changement.
- Demander un diagnostic
- France et Afrique francophone
Choisir une infrastructure proportionnée (IaaS/PaaS/SaaS), séparer les environnements, industrialiser avec CI/CD et l'observabilité, sans créer de dette d'exploitation.
Le bon niveau dépend du contrôle requis, des compétences disponibles, de la criticité, du coût et du rythme de changement.
Production, test et développement distincts, secrets stockés hors du dépôt Git, pipeline CI/CD avec rollback.
La perte de données acceptable et la durée de restauration maximale déterminent l'architecture, pas l'inverse.
Chaque partie traite un point de la démarche ; les liens ci-dessous mènent directement à la section correspondante.
Le NIST décrit le cloud à travers des caractéristiques comme l'accès à la demande, le partage de ressources, l'élasticité et la mesure du service, et distingue notamment IaaS (calcul, stockage et réseau, avec davantage de responsabilité côté client), PaaS (une plus grande partie de la plateforme d'exécution prise en charge) et SaaS (application complète livrée). Le bon choix dépend du niveau de contrôle requis, des compétences disponibles, de la criticité, du coût et du rythme de changement.
Un VPS peut être économique et flexible pour des charges prévisibles, mais l'organisation devient responsable du système, des correctifs, de la surveillance, des sauvegardes et de la sécurité. La bonne question n'est pas "quel hébergement est le moins cher ?" mais "quel coût total et quel niveau de risque pour maintenir le service pendant trois ans ?".
Production, test et développement doivent être séparés pour les systèmes significatifs, avec des secrets stockés dans un mécanisme adapté, jamais dans le dépôt Git ou un fichier partagé non contrôlé.
Un pipeline CI/CD peut automatiser tests, analyse statique, build, scan de dépendances, migration contrôlée, déploiement et vérifications post-déploiement. Pour les applications critiques : stratégie de rollback, sauvegarde avant migration, feature flags, health checks et contrôle des changements.
L'observabilité couvre trois familles classiques (logs, métriques, traces) plus les événements métier : un workflow peut être techniquement "up" alors qu'aucune facture n'a été créée depuis deux heures. Pour chaque service critique : disponibilité, latence, taux d'erreur, saturation et indicateurs métier, avec alertes et procédure d'escalade selon la criticité.
Une sauvegarde n'est pas validée parce qu'un fichier existe : il faut tester la restauration. Deux objectifs à définir : le RPO (quantité maximale de données que l'on accepte de perdre) et le RTO (durée maximale de restauration). Exemple du cours : un RPO de 15 minutes et un RTO de 2 heures imposent une architecture différente d'un site vitrine avec RPO 24 heures et RTO 48 heures. Le test réel d'une restauration figure d'ailleurs parmi les 10 vérifications essentielles de cybersécurité pour une PME.
Le FinOps suit les coûts par service, environnement et équipe, avec des budgets et alertes, en cherchant les ressources inutilisées, le surdimensionnement, le stockage oublié, le trafic sortant, les coûts d'API et la duplication d'environnements. Pour l'IA, le coût ne se limite pas aux tokens : indexation, stockage, outils, observabilité, évaluations et temps humain de validation et de reprise comptent aussi.
Ces écueils reviennent régulièrement en mission. Les identifier tôt évite de reconstruire un chantier déjà livré.
Prendre un VPS pour son prix sans intégrer correctifs, surveillance, sauvegardes et sécurité dans le coût réel.
Stocker des secrets dans le dépôt Git ou un fichier partagé non contrôlé.
Déployer sans stratégie de rollback ni sauvegarde préalable à la migration.
Compter le coût d'un projet IA en tokens seulement, en oubliant indexation, stockage, évaluations et validation humaine.
Nous dimensionnons l'infrastructure sur les besoins réels de continuité du client, puis nous documentons RPO, RTO et procédure de restauration, et nous testons cette restauration avant la mise en production.
Le RPO est la quantité maximale de données que l'on accepte de perdre, le RTO la durée maximale de restauration. Un RPO de 15 minutes avec un RTO de 2 heures impose une architecture très différente d'un site vitrine avec RPO 24 heures et RTO 48 heures.
Il automatise tests, analyse statique, build, scan de dépendances, migrations contrôlées, déploiement et vérifications post-déploiement, ce qui réduit les erreurs de mise en production et rend les retours arrière possibles.
En suivant les coûts par service, environnement et équipe, avec budgets et alertes, et en traquant les ressources inutilisées, le surdimensionnement, le stockage oublié, le trafic sortant, les coûts d'API et la duplication d'environnements.
Ce chapitre appartient au pilier « Construire un système fiable ». Architecture, données, infrastructure, automatisation, IA et cybersécurité : les capacités sur lesquelles reposent tous les usages métier.
Représenter le système d'information en six couches, définir la source de vérité de chaque donnée, et choisir entre acheter, configurer, intégrer ou développer.
Lire le chapitre →Chapitre 5Socle techniqueFaire de la donnée un actif utile : types de données, qualité, gouvernance, tableaux de bord orientés décision et préparation de la donnée pour l'IA.
Lire le chapitre →Chapitre 7Socle techniqueIdentifier les bons candidats à l'automatisation, choisir entre API, workflow, RPA ou agent IA, concevoir un workflow robuste et calculer son ROI réel.
Lire le chapitre →