Accès illimité 24h/24 à tous nos livres & vidéos ! Découvrez la Bibliothèque Numérique ENI. Cliquez ici.
  1. Livres et vidéos
  2. Les clés d'un progiciel SaaS durable - Aligner l'architecture, l'usine logicielle et l'organisation

Les clés d'un progiciel SaaS durable Aligner l'architecture, l'usine logicielle et l'organisation

  • En stock
  • Expédié en 24h00
  • Livraison à partir de 0,01 €
  • Version en ligne offerte pendant 1 an
  • 1 h d'accès gratuit à tous nos livres et vidéos pour chaque commande
  • Accessible immédiatement et pour une durée de 10 ans
  • Version HTML
  • Accès illimité 24h/24, 7J/7
  • Accès illimité 24h/24, 7J/7
  • Tous les livres en ligne, les vidéos et les cours enregistrés ENI
  • Plus de 10 nouveautés livres et vidéos chaque mois
  • Les nouveautés disponibles le jour de leur sortie
  • Accès 100% en ligne

Présentation

À 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

Table des matières

  • Une usine logicielle SaaS
    • 1. État des lieux des pratiques du SaaS
      • 1.1 Introduction
      • 1.2 Les éléments clés à maîtriser
      • 1.3 Contexte et contraintes clients
      • 1.4 La maîtrise des coûts du service
      • 1.5 Gestion des tests et de la livraison
      • 1.6 Infrastructure, DevOps et Cloud
      • 1.7 La gestion des ressources humaines
      • 1.8 Les architectures microservices
      • 1.9 Outillage
      • 1.10 Méthodes et organisations
    • 2. Modèle économique d’un acteur SaaS
      • 2.1 Introduction
      • 2.2 Vocabulaire spécifique du SaaS
      • 2.3 SaaS vs On Premise
      • 2.4 Spécificités financières du modèle SaaS
      • 2.5 La transition vers le SaaS
        • 2.5.1 Un mouvement général
        • 2.5.2 Analyse de marge d’un acteur de SaaS
        • 2.5.3 Les difficultés du modèle SaaS vues du client
        • 2.5.4 Transition du On Premise vers le SaaS
    • 3. Les produits délivrés par un acteur SaaS
      • 3.1 Introduction
      • 3.2 Produit d’Administration de la plateforme
        • 3.2.1 Le module de gestion des clients SaaS
        • 3.2.2 Le module dédié au Support
        • 3.2.3 Le module dédié au RUN
        • 3.2.4 Le module dédié aux opérations
        • 3.2.5 Offres de services complémentaires
      • 3.3 Produit d’Administration Client
        • 3.3.1 Module de gestion des tenants
        • 3.3.2 Module de pilotage d’un tenant
        • 3.3.3 Module de configuration client
        • 3.3.4 Module d’intégration client
        • 3.3.5 Module Client Data
      • 3.4 Produit SaaS
      • 3.5 Conclusion
    • 4. Personnaliser (ou non) une offre SaaS
      • 4.1 Le dilemme de la personnalisation
      • 4.2 La personnalisation de l’interface graphique
      • 4.3 La personnalisation des fonctions
      • 4.4 La customisation des flux
      • 4.5 La customisation des données
      • 4.6 Quelle stratégie en synthèse ?
  • Le DevOps au service du SaaS
    • 1. DevOps comme clé pour le SaaS
      • 1.1 Pourquoi DevOps ?
      • 1.2 Vue d’ensemble
      • 1.3 Les bonnes pratiques DevOps
      • 1.4 Les bénéfices - les métriques
      • 1.5 Organisation d’équipes DevOps
        • 1.5.1 Collaboration Développement et Opérations
        • 1.5.2 Équipe Plateforme
        • 1.5.3 Fusion Développement et Opérations
        • 1.5.4 Quel modèle remporte nos votes ?
    • 2. CI/CD : un processus à flux tirés
      • 2.1 Pourquoi une CI/CD ?
      • 2.2 L’intégration continue (CI)
      • 2.3 La livraison continue (CD)
      • 2.4 Le déploiement continu
      • 2.5 Les bonnes pratiques d’une CI/CD
        • 2.5.1 Big Picture de la CI/CD
        • 2.5.2 Revue de code et Test-First
        • 2.5.3 Feature Flipping
        • 2.5.4 Les tests bout en bout dans l’usine
    • 3. La qualité dans un processus DevOps
      • 3.1 Introduction
      • 3.2 Les mécanismes de relecture de code
      • 3.3 Le Test Driven Development
      • 3.4 Behaviour Driven Development
      • 3.5 Dette technique et objectivation de la qualité
    • 4. L'infrastructure au service de DevOps
      • 4.1 Introduction
      • 4.2 Les conteneurs
      • 4.3 Conteneurs ou VM
      • 4.4 La gestion de configuration
      • 4.5 Les origines de l’IaC
      • 4.6 Les principes de l’IaC
      • 4.7 Les bénéfices de l’IaC
      • 4.8 L’effort de mise en place de l’IaC
      • 4.9 Les principaux Frameworks d’IaC
    • 5. Les opérations
      • 5.1 Introduction
      • 5.2 Processus de mise à jour d’une version
        • 5.2.1 La nécessité impérieuse de mise à jour continue
        • 5.2.2 Packaging par la R&D
        • 5.2.3 Livraison R&D sur un serveur pour "Smoke Tests"
        • 5.2.4 Livraison sur les serveurs de recette de quelques tenants représentatifs de la production
        • 5.2.5 Livraison sur les serveurs de production
      • 5.3 Gestion des migrations de schéma des données
        • 5.3.1 Principes généraux
        • 5.3.2 Sharding
        • 5.3.3 Opérations destructrices
        • 5.3.4 Contraintes d’intégrité
        • 5.3.5 Ajout/modification/suppression de champs
      • 5.4 Processus de rollback et patch
      • 5.5 Stratégie de backup et de restauration
        • 5.5.1 Intérêt des backups
        • 5.5.2 Typologie des backups
        • 5.5.3 Stratégie des backups
        • 5.5.4 Backup et Cloud
        • 5.5.5 Alternatives
        • 5.5.6 Réplication active entre sites
        • 5.5.7 Le chiffrement des backups
      • 5.6 Plan de reprise d’activité (PRA)
        • 5.6.1 RTO/RPO
        • 5.6.2 PRA via l’IaC
      • 5.7 Gérer une crise
        • 5.7.1 Déclenchement de la crise
        • 5.7.2 Processus de résolution de crise
        • 5.7.3 Après la crise
      • 5.8 Les indicateurs de mesure de disponibilité des services SaaS
      • 5.9 Opérations autour de la sécurité
        • 5.9.1 Audit de sécurité
        • 5.9.2 Tests d’intrusion
      • 5.10 Nouvelles approches modernes
        • 5.10.1 Mise en place du Chaos Engineering
        • 5.10.2 Maintenance prédictive
        • 5.10.3 Bug Bounties
  • Le levier du Cloud
    • 1. Introduction
    • 2. Cloud - Les concepts IaaS, PaaS, SaaS, FaaS
      • 2.1 Introduction
      • 2.2 Modèle économique des XaaS
      • 2.3 IaaS
      • 2.4 PaaS
      • 2.5 SaaS
      • 2.6 Grille comparative
      • 2.7 FaaS/Serverless
    • 3. Régions, zones de disponibilité
    • 4. État des lieux des différents fournisseurs Cloud
      • 4.1 Liste des différents fournisseurs Cloud
        • 4.1.1 Les Majors
        • 4.1.2 Les autres offres
        • 4.1.3 Les acteurs historiques IaaS qui se convertissent au Cloud
      • 4.2 Les critères de choix
        • 4.2.1 La complétude fonctionnelle
        • 4.2.2 L’aspect tarifaire et la performance
        • 4.2.3 Les certifications
        • 4.2.4 Le support
        • 4.2.5 Les compétences disponibles
        • 4.2.6 Hébergement en France et en Europe
        • 4.2.7 Multi-cloud
    • 5. Consommer du IaaS, PaaS ou FaaS
    • 6. Optimiser ses coûts Cloud
      • 6.1 Introduction
      • 6.2 Les différents coûts en jeu
      • 6.3 Réduire sa facture Cloud
        • 6.3.1 Demander un crédit et/ou utiliser les Free Tiers
        • 6.3.2 Utiliser la scalabilité et la dynamicité à votre avantage
        • 6.3.3 Les consoles d’estimation des coûts
        • 6.3.4 L’utilisation d’instances réservées
        • 6.3.5 L’utilisation des "Instances" discount
        • 6.3.6 Les alertes
  • Stratégie pour un logiciel SaaS durable
    • 1. Construire et piloter sa roadmap
      • 1.1 Les enjeux critiques
      • 1.2 Construire sa roadmap
        • 1.2.1 Les trois niveaux de la roadmap
        • 1.2.2 Les métadonnées pour les enjeux transverses
        • 1.2.3 MVP et Story Mapping
      • 1.3 Piloter sa roadmap
        • 1.3.1 Diminuer les en-cours
        • 1.3.2 Gérer les dépendances
        • 1.3.3 Roadmap métier vs roadmap R&D
        • 1.3.4 Les instances de pilotage de la roadmap
    • 2. Choisir son architecture
      • 2.1 Du monolithe aux microservices
      • 2.2 Monolithe : de l’application simple à l’application à tout faire
      • 2.3 Le bus applicatif (SOA)
      • 2.4 Les microservices
        • 2.4.1 Les principes de l’architecture microservice
        • 2.4.2 La base de données en microservices
        • 2.4.3 Quelle granularité pour un microservice ?
      • 2.5 Monolithe, SOA, microservices en résumé...
      • 2.6 La productivité
      • 2.7 La scalabilité, clé de voûte de la croissance du SaaS
      • 2.8 La résilience et l'évolutivité du service SaaS
      • 2.9 Cycle de vie des applications
      • 2.10 Domain Driven Design
        • 2.10.1 La famille de relation "coopération"
        • 2.10.2 La famille de relation client-fournisseur
      • 2.11 Conclusion
    • 3. Quels langages pour quels usages ?
      • 3.1 Les motivations pour le choix d’un langage
      • 3.2 Les langages orientés "Systèmes"
        • 3.2.1 Rust
        • 3.2.2 Go
      • 3.3 Langages orientés "backend"
        • 3.3.1 C#/.NET
        • 3.3.2 Python
        • 3.3.3 Ruby
        • 3.3.4 PHP
        • 3.3.5 Java
        • 3.3.6 Scala
        • 3.3.7 Groovy
      • 3.4 Les langages et Framework orientés "frontend"
        • 3.4.1 JavaScript, TypeScript et NodeJS
        • 3.4.2 Framework Angular/ReactJS/Vue JS
        • 3.4.3 Kotlin
      • 3.5 Matrice d’usage
    • 4. Modélisation de l’usine SaaS et l’usine logicielle
      • 4.1 De la nécessité de modéliser
      • 4.2 Les trois types d’entités opérant du logiciel
        • 4.2.1 DSI
        • 4.2.2 Usine SaaS
        • 4.2.3 Usine logicielle pour le SaaS
        • 4.2.4 L’utilisation de la modélisation proposée
        • par les grands acteurs
        • 4.2.5 Le rôle du métamodèle dans la sûreté de fonctionnement
      • 4.3 Modèle et transformation de métamodèle
        • 4.3.1 Amener les équipes à adhérer à leur usine logicielle
        • 4.3.2 Exemples de transformation successive
        • 4.3.3 Convention de nommage et Convention Over Configuration
        • 4.3.4 Approche déclarative ou impérative pour configurer le modèle
        • 4.3.5 Introduction des tests dans l’usine logicielle
        • 4.3.6 Monorepositories ou multirepositories
      • 4.4 GitOps, mise en pratique de la métamodélisation
        • 4.4.1 Introduction
        • 4.4.2 Workflow GitOps
        • 4.4.3 Illustration d’une mise en œuvre de GitOps
        • 4.4.4 GitOps et sécurité
      • 4.5 Proposition de métamodèles pour l’usine SaaS et l’usine logicielle
        • 4.5.1 Modélisation des produits et des versions
        • 4.5.2 Modélisation de l’infrastructure
    • 5. Gestion des dépendances et de l’obsolescence
      • 5.1 Introduction
      • 5.2 Comment ce problème est-il devenu aussi prédominant ?
      • 5.3 Aspect Dette technique
      • 5.4 Aspect Support
      • 5.5 Aspect Conformité logicielle
        • 5.5.1 Le problème
        • 5.5.2 La solution
      • 5.6 Aspect Sécurité
        • 5.6.1 Le problème
        • 5.6.2 La solution
      • 5.7 Quel processus pour mettre à jour ses dépendances ?
        • 5.7.1 Réponse A : laisser les développeurs se débrouiller sans directives
        • 5.7.2 Réponse B : se reposer sur un héros qui œuvre en silence (souvent le soir, au calme)
        • 5.7.3 Réponse C : ne pas préciser les dépendances et utiliser systématiquement la dernière version
        • 5.7.4 Réponse D : faire de grandes campagnes de mises à jour tous les trois à quatre ans
        • 5.7.5 Notre proposition
      • 5.8 Quelle version choisir pour telle ou telle dépendance ?Stable, LTS, Bêta ?
      • 5.9 Par quoi commencer ?
      • 5.10 Quel outillage pour cette proposition ?
        • 5.10.1 Approche manuelle et systématique
        • 5.10.2 Outillage fourni par les derniers outils de gestion de source
      • 5.11 Conclusion
    • 6. La performance des applications
      • 6.1 Introduction
      • 6.2 Exigence des utilisateurs
      • 6.3 Des problèmes difficiles à résoudre
        • 6.3.1 La diversité des acteurs impliqués
        • 6.3.2 La nécessité d’un vocabulaire commun
      • 6.4 Typologie de Tests de performance
        • 6.4.1 Test de charge
        • 6.4.2 Test par palier
        • 6.4.3 Test de robustesse, d'endurance, de fiabilité
        • 6.4.4 Test aux limites/rupture
        • 6.4.5 Test de résilience
        • 6.4.6 Tests de temps de réponse avec variation de la puissance
      • 6.5 Processus de résolution
        • 6.5.1 Kick off
        • 6.5.2 Définir le statut
        • 6.5.3 Définir la cible
        • 6.5.4 Processus de résolution, points d’étape
        • 6.5.5 Constitution de l’équipe
      • 6.6 Les problèmes de performance les plus courants
        • 6.6.1 Utilisation des ORM
        • 6.6.2 Le manque d’index, l’altération des index ou l'excès d’index
        • 6.6.3 L’utilisation de lock excessifs
        • 6.6.4 Fuite mémoire/Garbage Collector
        • 6.6.5 Le piège du cache
        • 6.6.6 Le niveau de log trop élevé
        • 6.6.7 Le ratio de cœurs virtuels/physique
        • 6.6.8 Un mauvais fonctionnement du Load Balancer
        • 6.6.9 Autres problèmes d’infrastructure basique
      • 6.7 Résolution en phase de développement
      • 6.8 Résolution via un test de montée en charge
        • 6.8.1 Dimensionnement de l’infrastructure de tests
        • 6.8.2 Infrastructure d’injection
        • 6.8.3 Infrastructure de tests
        • 6.8.4 Plateforme de restitution
      • 6.9 Après la résolution
      • 6.10 Surveiller la performance en production
        • 6.10.1 Introduction aux APM
        • 6.10.2 Construire un APM avec des briques open source
        • 6.10.3 Outils tout-en-un
    • 7. User Experience
      • 7.1 Mobile First ou application web classique
      • 7.2 Externaliser ou non l’UI/UX
        • 7.2.1 Démarche générale
        • 7.2.2 Analyse de l'existant
        • 7.2.3 Implémentation
        • 7.2.4 Pérennisation
  • Patterns d’Architecture logicielle pour le SaaS
    • 1. Single Sign-On et Autorisations
      • 1.1 Les différents niveaux de maturité
      • 1.2 Gestion des mots de passe
        • 1.2.1 Sécurité du mot de passe
        • 1.2.2 Authentification à facteurs multiples
      • 1.3 Le SSO
        • 1.3.1 La notion de Royaume
        • 1.3.2 Principe de fonctionnement du SSO
        • 1.3.3 Utilisation d’un Identity Provider
        • 1.3.4 Utilisation d’un Federation Provider
        • 1.3.5 Autoprovisioning
        • 1.3.6 L’authentification Machine To Machine
      • 1.4 Autorisations/Permissions
        • 1.4.1 Modèle IBAC/RBAC
        • 1.4.2 Le modèle des policies
        • 1.4.3 Filtrer les données à partir des autorisations
        • 1.4.4 Traçabilité sur les autorisations/permissions
        • 1.4.5 Centralisation/décentralisation et autoprovisioning
    • 2. API/SDK
      • 2.1 Un peu d’histoire - Les SDKS
      • 2.2 Du besoin d’enrichir les logiciels SaaS
      • 2.3 Les API SOAP
        • 2.3.1 Approche Schema First
        • 2.3.2 Approche Code First
      • 2.4 Les API REST
        • 2.4.1 D’une application Single Page Application à une API First
        • 2.4.2 La documentation d’une API
        • 2.4.3 Test-First et approche SDK
      • 2.5 Des limites d’OpenAPI et l’approche GraphQL
      • 2.6 Gestion des API
        • 2.6.1 API Gateway
        • 2.6.2 Throttling
        • 2.6.3 Back-Pressure
        • 2.6.4 Les API asynchrones
        • 2.6.5 Montée de version des API
        • 2.6.6 Gérer le cycle de vie des API
      • 2.7 Conclusion
    • 3. Architectures multi-tenants
      • 3.1 Introduction
      • 3.2 Mono-tenant et multi-tenant
        • 3.2.1 Architecture mono-tenant
        • 3.2.2 Concept multi-tenant
        • 3.2.3 Architecture multi-tenant applicatif
        • 3.2.4 Multi-tenant au niveau bases de données
      • 3.3 Contraintes techniques du multi-tenant
        • 3.3.1 SPOF
        • 3.3.2 Le voisin bruyant
        • 3.3.3 Load Balancers
      • 3.4 Multi-tenant, haute disponibilité et clustering
        • 3.4.1 Introduction
        • 3.4.2 Un seul cluster pour tous les tenants
        • 3.4.3 Un cluster différent pour chaque tenant
        • 3.4.4 Séparation des clusters par client
        • 3.4.5 Séparation des clusters par type d’environnement
        • 3.4.6 Taille des clusters
        • 3.4.7 Comparatif des différentes stratégies de clustering
      • 3.5 Multi-tenant et microservices
        • 3.5.1 Séparation par microservices et clé de tenant
        • 3.5.2 Séparation par tenant et microservice
    • 4. Workflow et moteur de règles
      • 4.1 Introduction
      • 4.2 Le prix d’un moteur de workflow
      • 4.3 Le lien Workflow - Code source
      • 4.4 Les limites des workflows
      • 4.5 Gestion d’un contexte et lien avec le moteur de règles
      • 4.6 Gérer la complexité des règles dans le moteur de règles
        • 4.6.1 L’approche DSL
        • 4.6.2 L’approche "Table de paramétrages"
      • 4.7 Du moteur de règles au moteur de calcul
      • 4.8 Workflow, BAM et monitoring
    • 5. Gestion de tenants et du paramétrage
      • 5.1 Introduction
      • 5.2 Différents types de données pour un tenant
        • 5.2.1 Les données de paramétrage
        • 5.2.2 Les données de référentiels
        • 5.2.3 Les données opérationnelles
        • 5.2.4 Réversibilité d’un tenant (restitution des données)
      • 5.3 Gestion du cycle de vie des données
        • 5.3.1 Un besoin ubiquitaire
        • 5.3.2 Initialisation des données
      • 5.4 Transporter du paramétrage
        • 5.4.1 Cas métier nécessitant du transport de paramètres
        • 5.4.2 Gestion par import/export
        • 5.4.3 Outil de workflow de gestion de données
      • 5.5 Maîtrise de la qualité du paramétrage
        • 5.5.1 Paramétrage et code applicatif
        • 5.5.2 Compromis Paramétrage/Code
        • 5.5.3 Vers des pratiques communes sur le paramétrage et le code
        • 5.5.4 Les limites du cycle en V/cascade
        • 5.5.5 Paramétrage par incrément
        • 5.5.6 Validation via la revue de paramétrage
        • 5.5.7 Validation via des tests intégrés
      • 5.6 Conclusion
    • 6. Transactions, SAGA et CQRS
      • 6.1 Introduction
      • 6.2 L’approche transactionnelle classique : ACID
      • 6.3 Cohérence à Terme et Saga
      • 6.4 Théorème du CAP
      • 6.5 Niveau d’isolation des transactions
      • 6.6 CQRS
        • 6.6.1 Sans CQRS
        • 6.6.2 CQRS avec DDD
        • 6.6.3 CQRS sans DDD
        • 6.6.4 Conclusion
    • 7. Pattern de sécurisation réseau
      • 7.1 Introduction
      • 7.2 Le mouvement Zero Trust Architecture (ZTA)
      • 7.3 La gestion des clés d’authentification
      • 7.4 La gestion des certificats
        • 7.4.1 Principe des certificats
        • 7.4.2 Automatisation des certificats pour les utilisateurs de vos services
        • 7.4.3 Automatisation des certificats uniques entre applications
        • 7.4.4 Le SSL Offloading
      • 7.5 Les WAF
      • 7.6 Isolation des bases de données et des microservices
      • 7.7 Isolation des serveurs applicatifs
      • 7.8 Chiffrement du stockage
  • Organisation des équipes
    • 1. Les équipes
      • 1.1 Introduction
      • 1.2 Les types d’équipe
        • 1.2.1 Stream-aligned Team
        • 1.2.2 Platform Team
        • 1.2.3 Complicated-subsystem Team
        • 1.2.4 Enabling Team
      • 1.3 Le support client/l’intégration
      • 1.4 Les rôles au sein de l’équipe
        • 1.4.1 L’équipe Agile
        • 1.4.2 Product Owner
        • 1.4.3 Scrum Master
        • 1.4.4 Développeurs
        • 1.4.5 Technical Leader
        • 1.4.6 Quality Assurance
    • 2. Supporter la croissance des équipes
      • 2.1 La nécessité d’un cadre à l’échelle
      • 2.2 Manager l’humain dans un contexte à l’échelle
      • 2.3 Les dépendances entre équipes
        • 2.3.1 Les différents types de dépendances
        • 2.3.2 Le découplage des équipes par les interfaces
      • 2.4 Quelle gouvernance technique ?
      • 2.5 Propositions d’organisation par palier de croissance
        • 2.5.1 Les principaux rôles de management
        • 2.5.2 Quelle organisation pour une R&D de 25 personnes ?
        • 2.5.3 Quelle organisation pour une R&D de 50 personnes ?
        • 2.5.4 Quelle organisation pour une R&D de 100 personnes ?
        • 2.5.5 Quelle organisation pour une R&D de 250 personnes ?
    • 3. Processus de recrutement
      • 3.1 L’importance du recrutement
      • 3.2 Définir les postes
      • 3.3 Processus de recrutement
        • 3.3.1 Les enjeux du processus de recrutement
        • 3.3.2 Processus général
    • 4. Onboarding & Offboarding
      • 4.1 Introduction
      • 4.2 Onboarding
        • 4.2.1 Processus général
        • 4.2.2 Avant l’arrivée
        • 4.2.3 Le jour de l’arrivée
        • 4.2.4 Training Starter
        • 4.2.5 Mesurer l’efficience du Onboarding
      • 4.3 Offboarding
        • 4.3.1 Processus général
        • 4.3.2 Avant le départ
        • 4.3.3 Le jour du départ
      • 4.4 Onboarding & Offboarding comme miroirs de la culture SaaS
    • 5. Formation
    • Conclusion
    • Index

Auteurs

Stéphane VANACKEREn savoir plus

Après près de 20 ans d’expérience dans l’édition de logiciels, d’abord en tant que développeur, puis en tant qu’Engineering Manager sur des produits SaaS chez Talentsoft ou Cegedim, Stéphane VANACKER est actuellement CTO au sein d’Asys, éditeur de logiciel dans le domaine des Ressources Humaines. L’une de ses missions est la transformation SaaS et Cloud native de leurs solutions. Avec ce livre, il partage sa passion, son expérience et les clés pour optimiser les architectures à grande échelle n-tiers et distribuées, notamment en microservices et en SaaS.

Sylvain ASSEMATEn savoir plus

Après avoir fait ses armes pendant une dizaine d’années dans l’informatique industrielle en tant que développeur puis chef de projet, Sylvain ASSEMAT devient manager pour deux grands éditeurs de progiciels dans le domaine de la santé : Berger Levrault puis Cegedim. Depuis 2020, il exerce en tant que Software Manager pour l’éditeur de solutions de véhicules autonomes EasyMile et accompagne au quotidien une équipe d’un peu plus de 50 développeurs en système embarqué et contribue au système interne de Way of Working basé sur un modèle d’Agilité à l’échelle.

Caractéristiques

  • Niveau Confirmé à Initié
  • Nombre de pages 678 pages
  • Parution janvier 2022
    • Livre (broché) - 17 x 21 cm
    • ISBN : 978-2-409-03364-3
    • EAN : 9782409033643
    • Ref. ENI : DPLOGSAAS
  • Niveau Confirmé à Initié
  • Parution janvier 2022
    • HTML
    • ISBN : 978-2-409-03365-0
    • EAN : 9782409033650
    • Ref. ENI : LNDPLOGSAAS