À travers l’analyse des techniques de développement et l’approfondissement de celles qui apparaissent comme essentielles, ce livre transmet aux CTOs, managers R&D, architectes, lead tech, ou tout autre membre d’un service R&D, les clés pour réussir le développement d’un progiciel en mode SaaS. L’objectif est d’amener le lecteur à la maîtrise de ces techniques et à la compréhension de leur synergie pour lui permettre, en entreprise, de faire concorder l’architecture mise en place et l’usine logicielle.

Tout au long du livre, les auteurs s’appuient sur un exemple de création et d’exploitation d’un logiciel SaaS d’envergure, avec une visée B2B. Ils commencent par établir une cartographie des pratiques utilisées qui servira de base de discussion et de conciliation entre les parties prenantes managériale et technique, et plus globalement pour l’ensemble de l’entreprise. Ils détaillent ensuite la transformation DevOps et ses enjeux, notamment avec l’utilisation du Cloud comme levier d’innovation.

L'importance de l'usine logicielle est démontrée et vous découvrez en quoi sa modélisation peut assurer la pérennité et l’efficacité opérationnelle du service SaaS. Quelques patterns d’architecture et concepts incontournables pour la réussite de ce type de projet sont étudiés avant d’observer l’organisation des équipes concordant avec l’ensemble de ces pratiques.


Quizinclus dans
la version en ligne !

• Testez vos connaissances à l'issue de chaque chapitre
• Validez vos acquis

Avant-propos

1. Introduction

Une usine logicielle SaaS

1. État des lieux des pratiques du SaaS
   1. 1. Introduction
   2. 2. Les éléments clés à maîtriser
   3. 3. Contexte et contraintes clients
   4. 4. La maîtrise des coûts du service
   5. 5. Gestion des tests et de la livraison
   6. 6. Infrastructure, DevOps et Cloud
   7. 7. La gestion des ressources humaines
   8. 8. Les architectures microservices
   9. 9. Outillage
   10. 10. Méthodes et organisations
2. Modèle économique d’un acteur SaaS
   1. 1. Introduction
   2. 2. Vocabulaire spécifique du SaaS
   3. 3. SaaS vs On Premise
   4. 4. Spécificités financièresdu modèle SaaS
   5. 5. La transition vers le SaaS
      1. a. Un mouvement général
      2. b. Analyse de marge d’un acteur de SaaS
      3. c. Les difficultés du modèle SaaS vuesdu client
      4. d. Transition du On Premise vers le SaaS
3. Les produits délivrés par un acteur SaaS
   1. 1. Introduction
   2. 2. Produit d’Administration de la plateforme
      1. a. Le module de gestion des clients SaaS
      2. b. Le module dédié au Support
      3. c. Le module dédié au RUN
      4. d. Le module dédié aux opérations
      5. e. Offres de services complémentaires
   3. 3. Produit d’Administration Client
      1. a. Module de gestion des tenants
      2. b. Module de pilotage d’un tenant
      3. c. Module de configuration client
      4. d. Module d’intégration client
      5. e. Module Client Data
   4. 4. Produit SaaS
   5. 5. Conclusion
4. Personnaliser (ou non) une offre SaaS
   1. 1. Le dilemme de la personnalisation
   2. 2. La personnalisation de l’interface graphique
   3. 3. La personnalisation des fonctions
   4. 4. La customisation des flux
   5. 5. La customisation des données
   6. 6. Quelle stratégie en synthèse ?

Le DevOps au service du SaaS

1. DevOps comme clé pour le SaaS
   1. 1. Pourquoi DevOps ?
   2. 2. Vue d’ensemble
   3. 3. Les bonnes pratiques DevOps
   4. 4. Les bénéfices - les métriques
   5. 5. Organisation d’équipes DevOps
      1. a. Collaboration Développement et Opérations
      2. b. Équipe Plateforme
      3. c. Fusion Développement et Opérations
      4. d. Quel modèle remporte nos votes ?
2. CI/CD : un processus à flux tirés
   1. 1. Pourquoi une CI/CD ?
   2. 2. L’intégration continue (CI)
   3. 3. La livraison continue (CD)
   4. 4. Le déploiement continu
   5. 5. Les bonnes pratiques d’une CI/CD
      1. a. Big Picture de la CI/CD
      2. b. Revue de code et Test-First
      3. c. Feature Flipping
      4. d. Les tests bout en bout dans l’usine
3. La qualité dans un processus DevOps
   1. 1. Introduction
   2. 2. Les mécanismes de relecture de code
   3. 3. Le Test Driven Development
   4. 4. Behaviour Driven Development
   5. 5. Dette technique et objectivation de la qualité
4. L'infrastructure au service de DevOps
   1. 1. Introduction
   2. 2. Les conteneurs
   3. 3. Conteneurs ou VM
   4. 4. La gestion de configuration
   5. 5. Les origines de l’IaC
   6. 6. Les principes de l’IaC
   7. 7. Les bénéfices de l’IaC
   8. 8. L’effort de mise en place de l’IaC
   9. 9. Les principaux Frameworks d’IaC
5. Les opérations
   1. 1. Introduction
   2. 2. Processus de mise à jour d’une version
      1. a. La nécessité impérieusede mise à jour continue
      2. b. Packaging par la R&D
      3. c. Livraison R&D sur un serveur pour "Smoke Tests"
      4. d. Livraison sur les serveurs de recette de quelquestenants représentatifs de la production
      5. e. Livraison sur les serveurs de production
   3. 3. Gestion des migrations de schéma des données
      1. a. Principes généraux
      2. b. Sharding
      3. c. Opérations destructrices
      4. d. Contraintes d’intégrité
      5. e. Ajout/modification/suppression dechamps
   4. 4. Processus de rollback et patch
   5. 5. Stratégie de backup et de restauration
      1. a. Intérêt des backups
      2. b. Typologie des backups
      3. c. Stratégie des backups
      4. d. Backup et Cloud
      5. e. Alternatives
      6. f. Réplication active entre sites
      7. g. Le chiffrement des backups
   6. 6. Plan de reprise d’activité (PRA)
      1. a. RTO/RPO
      2. b. PRA via l’IaC
   7. 7. Gérer une crise
      1. a. Déclenchement de la crise
      2. b. Processus de résolution de crise
      3. c. Après la crise
   8. 8. Les indicateurs de mesure de disponibilité desservices SaaS
   9. 9. Opérations autour de la sécurité
      1. a. Audit de sécurité
      2. b. Tests d’intrusion
   10. 10. Nouvelles approches modernes
       1. a. Mise en place du Chaos Engineering
       2. b. Maintenance prédictive
       3. c. Bug Bounties

Le levier du Cloud

1. Introduction
2. Cloud - Les concepts IaaS, PaaS, SaaS, FaaS
   1. 1. Introduction
   2. 2. Modèle économique des XaaS
   3. 3. IaaS
   4. 4. PaaS
   5. 5. SaaS
   6. 6. Grille comparative
   7. 7. FaaS/Serverless
3. Régions, zones de disponibilité
4. État des lieux des différents fournisseurs Cloud
   1. 1. Liste des différents fournisseurs Cloud
      1. a. Les Majors
      2. b. Les autres offres
      3. c. Les acteurs historiques IaaS qui se convertissentau Cloud
   2. 2. Les critères de choix
      1. a. La complétude fonctionnelle
      2. b. L’aspect tarifaire et la performance
      3. c. Les certifications
      4. d. Le support
      5. e. Les compétences disponibles
      6. f. Hébergement en France et en Europe
      7. g. Multi-cloud
5. Consommer du IaaS, PaaS ou FaaS
6. Optimiser ses coûts Cloud
   1. 1. Introduction
   2. 2. Les différents coûts en jeu
   3. 3. Réduire sa facture Cloud
      1. a. Demander un crédit et/ou utiliserles Free Tiers
      2. b. Utiliser la scalabilité et la dynamicité à votreavantage
      3. c. Les consoles d’estimation des coûts
      4. d. L’utilisation d’instances réservées
      5. e. L’utilisation des "Instances" discount
      6. f. Les alertes

Stratégie pour un logiciel SaaS durable

1. Construire et piloter sa roadmap
   1. 1. Les enjeux critiques
   2. 2. Construire sa roadmap
      1. a. Les trois niveaux de la roadmap
      2. b. Les métadonnées pour les enjeuxtransverses
      3. c. MVP et Story Mapping
   3. 3. Piloter sa roadmap
      1. a. Diminuer les en-cours
      2. b. Gérer les dépendances
      3. c. Roadmap métier vs roadmap R&D
      4. d. Les instances de pilotage de la roadmap
2. Choisir son architecture
   1. 1. Du monolithe aux microservices
   2. 2. Monolithe : de l’application simple à l’application à tout faire
   3. 3. Le bus applicatif (SOA)
   4. 4. Les microservices
      1. a. Les principes de l’architecture microservice
      2. b. La base de données en microservices
      3. c. Quelle granularité pour un microservice ?
   5. 5. Monolithe, SOA, microservices en résumé...
   6. 6. La productivité
   7. 7. La scalabilité, clé de voûtede la croissance du SaaS
   8. 8. La résilience et l’évolutivité duservice SaaS
   9. 9. Cycle de vie des applications
   10. 10. Domain Driven Design
       1. a. La famille de relation "coopération"
       2. b. La famille de relation client-fournisseur
   11. 11. Conclusion
3. Quels langages pour quels usages ?
   1. 1. Les motivations pour le choix d’un langage
   2. 2. Les langages orientés "Systèmes"
      1. a. Rust
      2. b. Go
   3. 3. Langages orientés "backend"
      1. a. C#/.NET
      2. b. Python
      3. c. Ruby
      4. d. PHP
      5. e. Java
      6. f. Scala
      7. g. Groovy
   4. 4. Les langages et Framework orientés "frontend"
      1. a. JavaScript, TypeScript et NodeJS
      2. b. Framework Angular/ReactJS/Vue JS
      3. c. Kotlin
   5. 5. Matrice d’usage
4. Modélisation de l’usine SaaS et l’usine logicielle
   1. 1. De la nécessité de modéliser
   2. 2. Les trois types d’entités opérantdu logiciel
      1. a. DSI
      2. b. Usine SaaS
      3. c. Usine logicielle pour le SaaS
      4. d. L’utilisation de la modélisationproposée par les grands acteurs
      5. e. Le rôle du métamodèle dansla sûreté de fonctionnement
   3. 3. Modèle et transformation de métamodèle
      1. a. Amener les équipes à adhérer à leurusine logicielle 
      2. b. Exemples de transformation successive
      3. c. Convention de nommage et Convention Over Configuration
      4. d. Approche déclarative ou impérativepour configurer le modèle
      5. e. Introduction des tests dans l’usine logicielle
      6. f. Monorepositories ou multirepositories
   4. 4. GitOps, mise en pratique de la métamodélisation
      1. a. Introduction
      2. b. Workflow GitOps
      3. c. Illustration d’une mise en œuvrede GitOps
      4. d. GitOps et sécurité
   5. 5. Proposition de métamodèles pourl’usine SaaS et l’usine logicielle
      1. a. Modélisation des produits et des versions
      2. b. Modélisation de l’infrastructure
5. Gestion des dépendances et de l’obsolescence
   1. 1. Introduction
   2. 2. Comment ce problème est-il devenu aussi prédominant?
   3. 3. Aspect Dette technique
   4. 4. Aspect Support
   5. 5. Aspect Conformité logicielle
      1. a. Le problème
      2. b. La solution
   6. 6. Aspect Sécurité
      1. a. Le problème
      2. b. La solution
   7. 7. Quel processus pour mettre à jour ses dépendances?
      1. a. Réponse A : laisser les développeursse débrouiller sans directives
      2. b. Réponse B : se reposer sur un hérosqui œuvre en silence (souvent le soir, au calme)
      3. c. Réponse C : ne pas préciserles dépendances et utiliser systématiquement ladernière version
      4. d. Réponse D : faire de grandes campagnesde mises à jour tous les trois à quatre ans
      5. e. Notre proposition
   8. 8. Quelle version choisir pour telle ou telle dépendance? Stable, LTS, Bêta ?
   9. 9. Par quoi commencer ?
   10. 10. Quel outillage pour cette proposition ?
       1. a. Approche manuelle et systématique
       2. b. Outillage fourni par les derniers outils de gestionde source
   11. 11. Conclusion
6. La performance des applications
   1. 1. Introduction
   2. 2. Exigence des utilisateurs
   3. 3. Des problèmes difficiles à résoudre
      1. a. La diversité des acteurs impliqués
      2. b. La nécessité d’un vocabulairecommun
   4. 4. Typologie de Tests de performance
      1. a. Test de charge
      2. b. Test par palier
      3. c. Test de robustesse, d’endurance, de fiabilité
      4. d. Test aux limites/rupture
      5. e. Test de résilience
      6. f. Tests de temps de réponse avec variationde la puissance
   5. 5. Processus de résolution
      1. a. Kick off
      2. b. Définir le statut
      3. c. Définir la cible
      4. d. Processus de résolution, points d’étape
      5. e. Constitution de l’équipe
   6. 6. Les problèmes de performance les plus courants
      1. a. Utilisation des ORM
      2. b. Le manque d’index, l’altérationdes index ou l’excès d’index
      3. c. L’utilisation de lock excessifs
      4. d. Fuite mémoire/Garbage Collector
      5. e. Le piège du cache
      6. f. Le niveau de log trop élevé
      7. g. Le ratio de cœurs virtuels/physique
      8. h. Un mauvais fonctionnement du Load Balancer
      9. i. Autres problèmes d’infrastructurebasique
   7. 7. Résolution en phase de développement
   8. 8. Résolution via un test de montéeen charge
      1. a. Dimensionnement de l’infrastructure de tests
      2. b. Infrastructure d’injection
      3. c. Infrastructure de tests
      4. d. Plateforme de restitution
   9. 9. Après la résolution
   10. 10. Surveiller la performance en production
       1. a. Introduction aux APM
       2. b. Construire un APM avec des briques open source
       3. c. Outils tout-en-un
7. User Experience
   1. 1. Mobile First ou application web classique
   2. 2. Externaliser ou non l’UI/UX
      1. a. Démarche générale
      2. b. Analyse de l’existant
      3. c. Implémentation
      4. d. Pérennisation

Patterns d’Architecture logicielle pour le SaaS

1. Single Sign-On et Autorisations
   1. 1. Les différents niveaux de maturité
   2. 2. Gestion des mots de passe
      1. a. Sécurité du mot de passe
      2. b. Authentification à facteurs multiples
   3. 3. Le SSO
      1. a. La notion de Royaume
      2. b. Principe de fonctionnement du SSO
      3. c. Utilisation d’un Identity Provider
      4. d. Utilisation d’un Federation Provider
      5. e. Autoprovisioning
      6. f. L’authentification Machine To Machine
   4. 4. Autorisations/Permissions
      1. a. Modèle IBAC/RBAC
      2. b. Le modèle des policies
      3. c. Filtrer les données à partir desautorisations
      4. d. Traçabilité sur les autorisations/permissions
      5. e. Centralisation/décentralisationet autoprovisioning
2. API/SDK
   1. 1. Un peu d’histoire - Les SDKS
   2. 2. Du besoin d’enrichir les logiciels SaaS
   3. 3. Les API SOAP
      1. a. Approche Schema First
      2. b. Approche Code First
   4. 4. Les API REST
      1. a. D’une application Single Page Application à uneAPI First
      2. b. La documentation d’une API
      3. c. Test-First et approche SDK
   5. 5. Des limites d’OpenAPI et l’approcheGraphQL
   6. 6. Gestion des API
      1. a. API Gateway
      2. b. Throttling
      3. c. Back-Pressure
      4. d. Les API asynchrones
      5. e. Montée de version des API
      6. f. Gérer le cycle de vie des API
   7. 7. Conclusion
3. Architectures multi-tenants
   1. 1. Introduction
   2. 2. Mono-tenant et multi-tenant
      1. a. Architecture mono-tenant
      2. b. Concept multi-tenant
      3. c. Architecture multi-tenant applicatif
      4. d. Multi-tenant au niveau bases de données
   3. 3. Contraintes techniques du multi-tenant
      1. a. SPOF
      2. b. Le voisin bruyant
      3. c. Load Balancers
   4. 4. Multi-tenant, haute disponibilité et clustering
      1. a. Introduction
      2. b. Un seul cluster pour tous les tenants
      3. c. Un cluster différent pour chaque tenant
      4. d. Séparation des clusters par client
      5. e. Séparation des clusters par type d’environnement
      6. f. Taille des clusters
      7. g. Comparatif des différentes stratégiesde clustering
   5. 5. Multi-tenant et microservices
      1. a. Séparation par microservices et clé detenant
      2. b. Séparation par tenant et microservice
4. Workflow et moteur de règles
   1. 1. Introduction
   2. 2. Le prix d’un moteur de workflow
   3. 3. Le lien Workflow - Code source
   4. 4. Les limites des workflows
   5. 5. Gestion d’un contexte et lien avec le moteurde règles
   6. 6. Gérer la complexité des règlesdans le moteur de règles
      1. a. L’approche DSL
      2. b. L’approche "Table de paramétrages"
   7. 7. Du moteur de règles au moteur de calcul
   8. 8. Workflow, BAM et monitoring
5. Gestion de tenants et du paramétrage
   1. 1. Introduction
   2. 2. Différents types de données pourun tenant
      1. a. Les données de paramétrage
      2. b. Les données de référentiels
      3. c. Les données opérationnelles
      4. d. Réversibilité d’un tenant(restitution des données)
   3. 3. Gestion du cycle de vie des données
      1. a. Un besoin ubiquitaire
      2. b. Initialisation des données
   4. 4. Transporter du paramétrage
      1. a. Cas métier nécessitant du transportde paramètres
      2. b. Gestion par import/export
      3. c. Outil de workflow de gestion de données
   5. 5. Maîtrise de la qualité du paramétrage
      1. a. Paramétrage et code applicatif
      2. b. Compromis Paramétrage/Code
      3. c. Vers des pratiques communes sur le paramétrageet le code
      4. d. Les limites du cycle en V/cascade
      5. e. Paramétrage par incrément
      6. f. Validation via la revue de paramétrage
      7. g. Validation via des tests intégrés
   6. 6. Conclusion
6. Transactions, SAGA et CQRS
   1. 1. Introduction
   2. 2. L’approche transactionnelle classique :ACID
   3. 3. Cohérence à Terme et Saga
   4. 4. Théorème du CAP
   5. 5. Niveau d’isolation des transactions
   6. 6. CQRS
      1. a. Sans CQRS
      2. b. CQRS avec DDD
      3. c. CQRS sans DDD
      4. d. Conclusion
7. Pattern de sécurisation réseau
   1. 1. Introduction
   2. 2. Le mouvement Zero Trust Architecture (ZTA)
   3. 3. La gestion des clés d’authentification
   4. 4. La gestion des certificats
      1. a. Principe des certificats
      2. b. Automatisation des certificats pour les utilisateursde vos services
      3. c. Automatisation des certificats uniques entre applications
      4. d. Le SSL Offloading
   5. 5. Les WAF
   6. 6. Isolation des bases de données et des microservices
   7. 7. Isolation des serveurs applicatifs
   8. 8. Chiffrement du stockage

Organisation des équipes

1. Les équipes
   1. 1. Introduction
   2. 2. Les types d’équipe
      1. a. Stream-aligned Team
      2. b. Platform Team
      3. c. Complicated-subsystem Team
      4. d. Enabling Team
   3. 3. Le support client/l’intégration
   4. 4. Les rôles au sein de l’équipe
      1. a. L’équipe Agile
      2. b. Product Owner
      3. c. Scrum Master
      4. d. Développeurs
      5. e. Technical Leader
      6. f. Quality Assurance
2. Supporter la croissance des équipes
   1. 1. La nécessité d’un cadre à l’échelle
   2. 2. Manager l’humain dans un contexte à l’échelle
   3. 3. Les dépendances entre équipes
      1. a. Les différents types de dépendances
      2. b. Le découplage des équipes par lesinterfaces
   4. 4. Quelle gouvernance technique ?
   5. 5. Propositions d’organisation par palier decroissance
      1. a. Les principaux rôles de management
      2. b. Quelle organisation pour une R&D de 25 personnes?
      3. c. Quelle organisation pour une R&D de 50 personnes?
      4. d. Quelle organisation pour une R&D de 100 personnes?
      5. e. Quelle organisation pour une R&D de 250 personnes?
3. Processus de recrutement
   1. 1. L’importance du recrutement
   2. 2. Définir les postes
   3. 3. Processus de recrutement
      1. a. Les enjeux du processus de recrutement
      2. b. Processus général
4. Onboarding & Offboarding
   1. 1. Introduction
   2. 2. Onboarding
      1. a. Processus général
      2. b. Avant l’arrivée
      3. c. Le jour de l’arrivée
      4. d. Training Starter
      5. e. Mesurer l’efficience du Onboarding
   3. 3. Offboarding
      1. a. Processus général
      2. b. Avant le départ
      3. c. Le jour du départ
   4. 4. Onboarding & Offboarding comme miroirs de la culture SaaS
5. Formation

Conclusion

1. Conclusion