• Aide
  • Eurêkoi Eurêkoi

Livre

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

Résumé

Un guide pour comprendre les techniques et technologies de développement liées au service SaaS pour l'ensemble des métiers de la recherche et du développement (R&D). Les auteurs expliquent également comment créer et exploiter un logiciel de SaaS ou encore comment préparer et organiser les équipes concernées par la mise en place d'un SaaS. Version en ligne gratuite. ©Electre 2022


  • Autre(s) auteur(s)
  • Éditeur(s)
  • Date
    • C 2022
  • Notes
    • SaaS = Software as a service
    • La couv. porte en plus : "+ quiz" ; "Version numérique offerte ! pendant 1 an"
    • Contient un "flashcode" permettant d'accéder à un contenu via Internet
  • Langues
    • Français
  • Description matérielle
    • 1 vol. (678 p.) : ill., tabl., fig. ; 22 cm
  • Collections
  • Sujet(s)
  • ISBN
    • 978-2-409-03364-3
  • Indice
  • Quatrième de couverture
    • Les clés d'un progiciel SaaS durable

      Aligner l'architecture, l'usine logicielle et l'organisation

      À 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.


  • Tables des matières
      • Les clés d'un progiciel SaaS durable

      • Aligner l'architecture, l'usine logicielle et l'organisation

      • Eni

      • Avant-propos
      • Chapitre 1
      • Une usine logicielle SaaS
      • 1. État des lieux des pratiques du SaaS17
      • 1.1 Introduction17
      • 1.2 Les éléments clés à maîtriser18
      • 1.3 Contexte et contraintes clients22
      • 1.4 La maîtrise des coûts du service24
      • 1.5 Gestion des tests et de la livraison27
      • 1.6 Infrastructure, DevOps et Cloud32
      • 1.7 La gestion des ressources humaines35
      • 1.8 Les architectures microservices37
      • 1.9 Outillage39
      • 1.10 Méthodes et organisations41
      • 2. Modèle économique d'un acteur SaaS46
      • 2.1 Introduction46
      • 2.2 Vocabulaire spécifique du SaaS46
      • 2.3 SaaS vs On Premise48
      • 2.4 Spécificités financières du modèle SaaS49
      • 2.5 La transition vers le SaaS50
      • 2.5.1 Un mouvement général50
      • 2.5.2 Analyse de marge d'un acteur de SaaS51
      • 2.5.3 Les difficultés du modèle SaaS vues du client57
      • 2.5.4 Transition du On Premise vers le SaaS58
      • 3. Les produits délivrés par un acteur SaaS59
      • 3.1 Introduction59
      • 3.2 Produit d'Administration de la plateforme62
      • 3.2.1 Le module de gestion des clients SaaS62
      • 3.2.2 Le module dédié au Support63
      • 3.2.3 Le module dédié au RUN63
      • 3.2.4 Le module dédié aux opérations63
      • 3.2.5 Offres de services complémentaires65
      • 3.3 Produit d'Administration Client65
      • 3.3.1 Module de gestion des tenants66
      • 3.3.2 Module de pilotage d'un tenant66
      • 3.3.3 Module de configuration client67
      • 3.3.4 Module d'intégration client67
      • 3.3.5 Module Client Data67
      • 3.4 Produit SaaS68
      • 3.5 Conclusion69
      • 4. Personnaliser (ou non) une offre SaaS70
      • 4.1 Le dilemme de la personnalisation70
      • 4.2 La personnalisation de l'interface graphique70
      • 4.3 La personnalisation des fonctions72
      • 4.4 La customisation des flux72
      • 4.5 La customisation des données74
      • 4.6 Quelle stratégie en synthèse ?75
      • Chapitre 2
      • Le DevOps au service du SaaS
      • 1. DevOps comme clé pour le SaaS77
      • 1.1 Pourquoi DevOps ?77
      • 1.2 Vue d'ensemble77
      • 1.3 Les bonnes pratiques DevOps78
      • 1.4 Les bénéfices - les métriques83
      • 1.5 Organisation d'équipes DevOps86
      • 1.5.1 Collaboration Développement et Opérations87
      • 1.5.2 Équipe Plateforme88
      • 1.5.3 Fusion Développement et Opérations88
      • 1.5.4 Quel modèle remporte nos votes ?89
      • 2. CI/CD : un processus à flux tirés91
      • 2.1 Pourquoi une CI/CD ?91
      • 2.2 L'intégration continue (CI)92
      • 2.3 La livraison continue (CD)96
      • 2.4 Le déploiement continu97
      • 2.5 Les bonnes pratiques d'une CI/CD98
      • 2.5.1 Big Picture de la CI/CD98
      • 2.5.2 Revue de code et Test-First99
      • 2.5.3 Feature Flipping100
      • 2.5.4 Les tests bout en bout dans l'usine104
      • 3. La qualité dans un processus DevOps111
      • 3.1 Introduction111
      • 3.2 Les mécanismes de relecture de code111
      • 3.3 Le Test Driven Development116
      • 3.4 Behaviour Driven Development118
      • 3.5 Dette technique et objectivation de la qualité121
      • 4. L'infrastructure au service de DevOps128
      • 4.1 Introduction128
      • 4.2 Les conteneurs128
      • 4.3 Conteneurs ou VM129
      • 4.4 La gestion de configuration133
      • 4.5 Les origines de l'IaC134
      • 4.6 Les principes de l'IaC136
      • 4.7 Les bénéfices de l'IaC137
      • 4.8 L'effort de mise en place de l'IaC138
      • 4.9 Les principaux Frameworks d'IaC139
      • 5. Les opérations143
      • 5.1 Introduction143
      • 5.2 Processus de mise à jour d'une version143
      • 5.2.1 La nécessité impérieuse de mise à jour continue143
      • 5.2.2 Packaging par la R&D144
      • 5.2.3 Livraison R&D sur un serveur pour « Smoke Tests »145
      • 5.2.4 Livraison sur les serveurs de recette de quelques tenants représentatifs de la production145
      • 5.2.5 Livraison sur les serveurs de production146
      • 5.3 Gestion des migrations de schéma des données148
      • 5.3.1 Principes généraux148
      • 5.3.2 Sharding149
      • 5.3.3 Opérations destructrices150
      • 5.3.4 Contraintes d'intégrité150
      • 5.3.5 Ajout/modification/suppression de champs150
      • 5.4 Processus de rollback et patch152
      • 5.5 Stratégie de backup et de restauration153
      • 5.5.1 Intérêt des backups153
      • 5.5.2 Typologie des backups154
      • 5.5.3 Stratégie des backups156
      • 5.5.4 Backup et Cloud157
      • 5.5.5 Alternatives158
      • 5.5.6 Réplication active entre sites158
      • 5.5.7 Le chiffrement des backups159
      • 5.6 Plan de reprise d'activité (PRA)159
      • 5.6.1 RTO/RPO159
      • 5.6.2 PRA via l'IaC161
      • 5.7 Gérer une crise162
      • 5.7.1 Déclenchement de la crise162
      • 5.7.2 Processus de résolution de crise163
      • 5.7.3 Après la crise164
      • 5.8 Les indicateurs de mesure de disponibilité des services SaaS165
      • 5.9 Opérations autour de la sécurité166
      • 5.9.1 Audit de sécurité166
      • 5.9.2 Tests d'intrusion169
      • 5.10 Nouvelles approches modernes171
      • 5.10.1 Mise en place du Chaos Engineering171
      • 5.10.2 Maintenance prédictive175
      • 5.10.3 Bug Bounties176
      • Chapitre 3
      • Le levier du Cloud
      • 1. Introduction179
      • 2. Cloud - Les concepts IaaS, PaaS, SaaS, FaaS180
      • 2.1 Introduction180
      • 2.2 Modèle économique des XaaS181
      • 2.3 IaaS185
      • 2.4 PaaS185
      • 2.5 SaaS186
      • 2.6 Grille comparative186
      • 2.7 FaaS/Serverless187
      • 3. Régions, zones de disponibilité189
      • 4. État des lieux des différents fournisseurs Cloud194
      • 4.1 Liste des différents fournisseurs Cloud194
      • 4.1.1 Les Majors194
      • 4.1.2 Les autres offres196
      • 4.1.3 Les acteurs historiques IaaS qui se convertissent au Cloud197
      • 4.2 Les critères de choix198
      • 4.2.1 La complétude fonctionnelle198
      • 4.2.2 L'aspect tarifaire et la performance202
      • 4.2.3 Les certifications202
      • 4.2.4 Le support204
      • 4.2.5 Les compétences disponibles205
      • 4.2.6 Hébergement en France et en Europe205
      • 4.2.7 Multi-cloud206
      • 5. Consommer du IaaS, PaaS ou FaaS207
      • 6. Optimiser ses coûts Cloud213
      • 6.1 Introduction213
      • 6.2 Les différents coûts en jeu213
      • 6.3 Réduire sa facture Cloud217
      • 6.3.1 Demander un crédit et/ou utiliser les Free Tiers217
      • 6.3.2 Utiliser la scalabilité et la dynamicité à votre avantage217
      • 6.3.3 Les consoles d'estimation des coûts218
      • 6.3.4 L'utilisation d'instances réservées218
      • 6.3.5 L'utilisation des « Instances » discount219
      • 6.3.6 Les alertes221
      • Chapitre 4
      • Stratégie pour un logiciel SaaS durable
      • 1. Construire et piloter sa roadmap225
      • 1.1 Les enjeux critiques225
      • 1.2 Construire sa roadmap226
      • 1.2.1 Les trois niveaux de la roadmap226
      • 1.2.2 Les métadonnées pour les enjeux transverses230
      • 1.2.3 MVP et Story Mapping230
      • 1.3 Piloter sa roadmap232
      • 1.3.1 Diminuer les en-cours232
      • 1.3.2 Gérer les dépendances234
      • 1.3.3 Roadmap métier vs roadmap R&D235
      • 1.3.4 Les instances de pilotage de la roadmap236
      • 2. Choisir son architecture237
      • 2.1 Du monolithe aux microservices237
      • 2.2 Monolithe : de l'application simple à l'application à tout faire239
      • 2.3 Le bus applicatif (SOA)241
      • 2.4 Les microservices243
      • 2.4.1 Les principes de l'architecture microservice243
      • 2.4.2 La base de données en microservices244
      • 2.4.3 Quelle granularité pour un microservice ?246
      • 2.5 Monolithe, SOA, microservices en résumé247
      • 2.6 La productivité249
      • 2.7 La scalabilité, clé de voûte de la croissance du SaaS250
      • 2.8 La résilience et l'évolutivité du service SaaS253
      • 2.9 Cycle de vie des applications254
      • 2.10 Domain Driven Design258
      • 2.10.1 La famille de relation « coopération »262
      • 2.10.2 La famille de relation client-fournisseur263
      • 2.11 Conclusion266
      • 3. Quels langages pour quels usages ?267
      • 3.1 Les motivations pour le choix d'un langage267
      • 3.2 Les langages orientés « Systèmes »270
      • 3.2.1 Rust270
      • 3.2.2 Go272
      • 3.3 Langages orientés « backend »272
      • 3.3.1 C#/.NET272
      • 3.3.2 Python274
      • 3.3.3 Ruby274
      • 3.3.4 PHP275
      • 3.3.5 Java276
      • 3.3.6 Scala277
      • 3.3.7 Groovy278
      • 3.4 Les langages et Framework orientés « frontend »278
      • 3.4.1 JavaScript, TypeScript et NodeJS278
      • 3.4.2 Framework Angular/ReactJS/Vue JS280
      • 3.4.3 Kotlin280
      • 3.5 Matrice d'usage281
      • 4. Modélisation de l'usine SaaS et l'usine logicielle282
      • 4.1 De la nécessité de modéliser282
      • 4.2 Les trois types d'entités opérant du logiciel283
      • 4.2.1 DSI284
      • 4.2.2 Usine SaaS286
      • 4.2.3 Usine logicielle pour le SaaS292
      • 4.2.4 L'utilisation de la modélisation proposée par les grands acteurs296
      • 4.2.5 Le rôle du métamodèle dans la sûreté de fonctionnement297
      • 4.3 Modèle et transformation de métamodèle297
      • 4.3.1 Amener les équipes à adhérer à leur usine logicielle297
      • 4.3.2 Exemples de transformation successive299
      • 4.3.3 Convention de nommage et Convention Over Configuration301
      • 4.3.4 Approche déclarative ou impérative pour configurer le modèle302
      • 4.3.5 Introduction des tests dans l'usine logicielle304
      • 4.3.6 Monorepositories ou multirepositories308
      • 4.4 GitOps, mise en pratique de la métamodélisation310
      • 4.4.1 Introduction310
      • 4.4.2 Workflow GitOps311
      • 4.4.3 Illustration d'une mise en oeuvre de GitOps314
      • 4.4.4 GitOps et sécurité316
      • 4.5 Proposition de métamodèles pour l'usine SaaS et l'usine logicielle317
      • 4.5.1 Modélisation des produits et des versions317
      • 4.5.2 Modélisation de l'infrastructure325
      • 5. Gestion des dépendances et de l'obsolescence330
      • 5.1 Introduction330
      • 5.2 Comment ce problème est-il devenu aussi prédominant ?330
      • 5.3 Aspect Dette technique332
      • 5.4 Aspect Support334
      • 5.5 Aspect Conformité logicielle336
      • 5.5.1 Le problème336
      • 5.5.2 La solution336
      • 5.6 Aspect Sécurité337
      • 5.6.1 Le problème337
      • 5.6.2 La solution337
      • 5.7 Quel processus pour mettre à jour ses dépendances ?338
      • 5.7.1 Réponse A : laisser les développeurs se débrouiller sans directives338
      • 5.7.2 Réponse B : se reposer sur un héros qui oeuvre en silence (souvent le soir, au calme)339
      • 5.7.3 Réponse C : ne pas préciser les dépendances et utiliser systématiquement la dernière version340
      • 5.7.4 Réponse D : faire de grandes campagnes de mises à jour tous les trois à quatre ans340
      • 5.7.5 Notre proposition341
      • 5.8 Quelle version choisir pour telle ou telle dépendance ? Stable, LTS, Bêta ?343
      • 5.9 Par quoi commencer ?345
      • 5.10 Quel outillage pour cette proposition ?348
      • 5.10.1 Approche manuelle et systématique348
      • 5.10.2 Outillage fourni par les derniers outils de gestion de source348
      • 5.11 Conclusion349
      • 6. La performance des applications350
      • 6.1 Introduction350
      • 6.2 Exigence des utilisateurs351
      • 6.3 Des problèmes difficiles à résoudre352
      • 6.3.1 La diversité des acteurs impliqués352
      • 6.3.2 La nécessité d'un vocabulaire commun352
      • 6.4 Typologie de Tests de performance353
      • 6.4.1 Test de charge353
      • 6.4.2 Test par palier353
      • 6.4.3 Test de robustesse, d'endurance, de fiabilité354
      • 6.4.4 Test aux limites/rupture354
      • 6.4.5 Test de résilience355
      • 6.4.6 Tests de temps de réponse avec variation de la puissance356
      • 6.5 Processus de résolution358
      • 6.5.1 Kick off359
      • 6.5.2 Définir le statut359
      • 6.5.3 Définir la cible360
      • 6.5.4 Processus de résolution, points d'étape366
      • 6.5.5 Constitution de l'équipe366
      • 6.6 Les problèmes de performance les plus courants367
      • 6.6.1 Utilisation des ORM367
      • 6.6.2 Le manque d'index, l'altération des index ou l'excès d'index372
      • 6.6.3 L'utilisation de lock excessifs374
      • 6.6.4 Fuite mémoire/Garbage Collector374
      • 6.6.5 Le piège du cache376
      • 6.6.6 Le niveau de log trop élevé377
      • 6.6.7 Le ratio de coeurs virtuels/physique378
      • 6.6.8 Un mauvais fonctionnement du Load Balancer379
      • 6.6.9 Autres problèmes d'infrastructure basique379
      • 6.7 Résolution en phase de développement381
      • 6.8 Résolution via un test de montée en charge382
      • 6.8.1 Dimensionnement de l'infrastructure de tests383
      • 6.8.2 Infrastructure d'injection384
      • 6.8.3 Infrastructure de tests388
      • 6.8.4 Plateforme de restitution389
      • 6.9 Après la résolution391
      • 6.10 Surveiller la performance en production391
      • 6.10.1 Introduction aux APM391
      • 6.10.2 Construire un APM avec des briques open source392
      • 6.10.3 Outils tout-en-un394
      • 7. User Experience395
      • 7.1 Mobile First ou application web classique397
      • 7.2 Externaliser ou non l'UI/UX398
      • 7.2.1 Démarche générale398
      • 7.2.2 Analyse de l'existant401
      • 7.2.3 Implémentation403
      • 7.2.4 Pérennisation405
      • Chapitre 5
      • Patterns d'Architecture logicielle pour le SaaS
      • 1. Single Sign-On et Autorisations409
      • 1.1 Les différents niveaux de maturité409
      • 1.2 Gestion des mots de passe411
      • 1.2.1 Sécurité du mot de passe411
      • 1.2.2 Authentification à facteurs multiples416
      • 1.3 Le SSO419
      • 1.3.1 La notion de Royaume419
      • 1.3.2 Principe de fonctionnement du SSO420
      • 1.3.3 Utilisation d'un Identity Provider422
      • 1.3.4 Utilisation d'un Fédération Provider422
      • 1.3.5 Autoprovisioning427
      • 1.3.6 L'authentification Machine To Machine428
      • 1.4 Autorisations/Permissions430
      • 1.4.1 Modèle IBAC/RBAC430
      • 1.4.2 Le modèle des policies431
      • 1.4.3 Filtrer les données à partir des autorisations432
      • 1.4.4 Traçabilité sur les autorisations/permissions433
      • 1.4.5 Centralisation/décentralisation et autoprovisioning433
      • 2. API/SDK434
      • 2.1 Un peu d'histoire - Les SDKS434
      • 2.2 Du besoin d'enrichir les logiciels SaaS435
      • 2.3 Les API SOAP439
      • 2.3.1 Approche Schéma First440
      • 2.3.2 Approche Code First441
      • 2.4 Les API REST444
      • 2.4.1 D'une application Single Page Application à une API First448
      • 2.4.2 La documentation d'une API450
      • 2.4.3 Test-First et approche SDK455
      • 2.5 Des limites d'OpenAPI et l'approche GraphQL457
      • 2.6 Gestion des API460
      • 2.6.1 API Gateway460
      • 2.6.2 Throttling462
      • 2.6.3 Back-Pressure463
      • 2.6.4 Les API asynchrones465
      • 2.6.5 Montée de version des API467
      • 2.6.6 Gérer le cycle de vie des API468
      • 2.7 Conclusion469
      • 3. Architectures multi-tenants470
      • 3.1 Introduction470
      • 3.2 Mono-tenant et multi-tenant472
      • 3.2.1 Architecture mono-tenant472
      • 3.2.2 Concept multi-tenant473
      • 3.2.3 Architecture multi-tenant applicatif474
      • 3.2.4 Multi-tenant au niveau bases de données476
      • 3.3 Contraintes techniques du multi-tenant480
      • 3.3.1 SPOF480
      • 3.3.2 Le voisin bruyant481
      • 3.3.3 Load Balancers481
      • 3.4 Multi-tenant, haute disponibilité et clustering484
      • 3.4.1 Introduction484
      • 3.4.2 Un seul cluster pour tous les tenants486
      • 3.4.3 Un cluster différent pour chaque tenant487
      • 3.4.4 Séparation des clusters par client488
      • 3.4.5 Séparation des clusters par type d'environnement489
      • 3.4.6 Taille des clusters489
      • 3.4.7 Comparatif des différentes stratégies de clustering491
      • 3.5 Multi-tenant et microservices491
      • 3.5.1 Séparation par microservices et clé de tenant492
      • 3.5.2 Séparation par tenant et microservice493
      • 4. Workflow et moteur de règles495
      • 4.1 Introduction495
      • 4.2 Le prix d'un moteur de workflow497
      • 4.3 Le lien Workflow - Code source497
      • 4.4 Les limites des workflows498
      • 4.5 Gestion d'un contexte et lien avec le moteur de règles500
      • 4.6 Gérer la complexité des règles dans le moteur de règles502
      • 4.6.1 L'approche DSL502
      • 4.6.2 L'approche « Table de paramétrages »505
      • 4.7 Du moteur de règles au moteur de calcul506
      • 4.8 Workflow, BAM et monitoring507
      • 5. Gestion de tenants et du paramétrage508
      • 5.1 Introduction508
      • 5.2 Différents types de données pour un tenant509
      • 5.2.1 Les données de paramétrage510
      • 5.2.2 Les données de référentiels514
      • 5.2.3 Les données opérationnelles515
      • 5.2.4 Réversibilité d'un tenant (restitution des données)516
      • 5.3 Gestion du cycle de vie des données517
      • 5.3.1 Un besoin ubiquitaire517
      • 5.3.2 Initialisation des données522
      • 5.4 Transporter du paramétrage529
      • 5.4.1 Cas métier nécessitant du transport de paramètres529
      • 5.4.2 Gestion par import/export529
      • 5.4.3 Outil de workflow de gestion de données531
      • 5.5 Maîtrise de la qualité du paramétrage533
      • 5.5.1 Paramétrage et code applicatif533
      • 5.5.2 Compromis Paramétrage/Code537
      • 5.5.3 Vers des pratiques communes sur le paramétrage et le code538
      • 5.5.4 Les limites du cycle en V/cascade539
      • 5.5.5 Paramétrage par incrément544
      • 5.5.6 Validation via la revue de paramétrage551
      • 5.5.7 Validation via des tests intégrés552
      • 5.6 Conclusion557
      • 6. Transactions, SAGA et CQRS558
      • 6.1 Introduction558
      • 6.2 L'approche transactionnelle classique : ACID559
      • 6.3 Cohérence à Terme et Saga560
      • 6.4 Théorème du CAP562
      • 6.5 Niveau d'isolation des transactions564
      • 6.6 CQRS567
      • 6.6.1 Sans CQRS567
      • 6.6.2 CQRS avec DDD569
      • 6.6.3 CQRS sans DDD571
      • 6.6.4 Conclusion571
      • 7. Pattern de sécurisation réseau572
      • 7.1 Introduction572
      • 7.2 Le mouvement Zéro Trust Architecture (ZTA)573
      • 7.3 La gestion des clés d'authentification577
      • 7.4 La gestion des certificats578
      • 7.4.1 Principe des certificats578
      • 7.4.2 Automatisation des certificats pour les utilisateurs de vos services580
      • 7.4.3 Automatisation des certificats uniques entre applications581
      • 7.4.4 Le SSL Offloading581
      • 7.5 Les WAF582
      • 7.6 Isolation des bases de données et des microservices583
      • 7.7 Isolation des serveurs applicatifs584
      • 7.8 Chiffrement du stockage585
      • Chapitre 6
      • Organisation des équipes
      • 1. Les équipes587
      • 1.1 Introduction587
      • 1.2 Les types d'équipe590
      • 1.2.1 Stream-aligned Team590
      • 1.2.2 Platform Team591
      • 1.2.3 Complicated-subsystem Team593
      • 1.2.4 Enabling Team594
      • 1.3 Le support client/l'intégration595
      • 1.4 Les rôles au sein de l'équipe600
      • 1.4.1 L'équipe Agile600
      • 1.4.2 Product Owner602
      • 1.4.3 Scrum Master603
      • 1.4.4 Développeurs603
      • 1.4.5 Technical Leader604
      • 1.4.6 Quality Assurance604
      • 2. Supporter la croissance des équipes605
      • 2.1 La nécessité d'un cadre à l'échelle605
      • 2.2 Manager l'humain dans un contexte à l'échelle609
      • 2.3 Les dépendances entre équipes611
      • 2.3.1 Les différents types de dépendances611
      • 2.3.2 Le découplage des équipes par les interfaces613
      • 2.4 Quelle gouvernance technique ?615
      • 2.5 Propositions d'organisation par palier de croissance619
      • 2.5.1 Les principaux rôles de management619
      • 2.5.2 Quelle organisation pour une R&D de 25 personnes ?620
      • 2.5.3 Quelle organisation pour une R&D de 50 personnes ?621
      • 2.5.4 Quelle organisation pour une R&D de 100 personnes ?623
      • 2.5.5 Quelle organisation pour une R&D de 250 personnes ?625
      • 3. Processus de recrutement626
      • 3.1 L'importance du recrutement626
      • 3.2 Définir les postes626
      • 3.3 Processus de recrutement627
      • 3.3.1 Les enjeux du processus de recrutement627
      • 3.3.2 Processus général630
      • 4. Onboarding St Offboarding635
      • 4.1 Introduction635
      • 4.2 Onboarding636
      • 4.2.1 Processus général636
      • 4.2.2 Avant l'arrivée637
      • 4.2.3 Le jour de l'arrivée637
      • 4.2.4 Training Starter639
      • 4.2.5 Mesurer l'efficience du Onboarding640
      • 4.3 Offboarding641
      • 4.3.1 Processus général641
      • 4.3.2 Avant le départ641
      • 4.3.3 Le jour du départ642
      • 4.4 Onboarding & Offboarding comme miroirs de la culture SaaS642
      • 5. Formation643
      • Conclusion647
      • Index651

  • Origine de la notice:
    • Abes ;
    • Electre
  • Disponible - 681.51 ASS

    Niveau 3 - Informatique