2. Ce que vous retenez...
“DevOps est une idéologie”
“Super échange”
“Former les équipes !”
“Communauté”
“Echanges”
“Participatif”
“Mélanger dev et ops est incontournable. Il n'y a pas de
'recette' qui marche à tous les coups.”
“La transformation DevOps nécessite de passer par de
l’intraprenariat”
“Il n’y a pas d’organisation type…”
“L’intelligence collective est l’enjeu d’une
transformation Cloud”
“La communication semble être le plus important”
“La démarche permettant de commencer à déployer la
culture Devops dans des organisations”
3.
4. L’ENTREPRISE PLATEFORME
Christine Ebadi, Responsable du Lab de Transformation & Innovation
Icelab by D2SI
Comment accompagner les métiers / profils non techs ?
■ Créer des communautés de partage entre pairs techs et non techs
■ Créer des communautés mixtes > par sujet et non par compétence
■ Former en impliquant dans les projets > Apprendre par
l’expérimentation
Débat sur le planning d’une transformation d'organisation > tout le monde est d’accord sur le fait
que mettre en place un micro-planning détaillé est impossible, mais il y a un réel besoin d’échelonner et
de donner de la visibilité au management
Comment convaincre le top management ?
● Souvent convaincu > ces nouveaux modèles d'organisation / de culture sont dans l’ère du temps
● La difficulté est souvent quand les managers pensent avoir déjà mis en place une organisation
décentralisée / culture collaborative et apprenante alors que ce n’est pas le cas > démontrer qu’ils
sont dans la bonne démarche mais qu’il reste du chemin à parcourir
5. Le DevOps n’est pas une fin en soi mais une démarche
Nécessité d’aller plus loin sur comment faire parler / échanger (et travailler ensemble) les
différents profils :
● Pour cela, il ne faut pas que chacun·e s’identifie à son métier ou à son silo mais bel et bien à sa
propre personne / identité avec ses aspirations personnelles.
Que deviennent les architectes, comment leur rôle évolue ?
● Le besoin d’architecture est toujours là mais l’architecte est amené·e à élargir son champ
d’action sur le produit dans son ensemble (run y compris) et être associé·e/”solidaire” de
la vie du produit (et pas simplement en amont)
● Sa mise en oeuvre peut varier selon la taille de l’organisation mais on sort du rôle “exclusif” - ie
portée uniquement par une personne ou un groupe de personnes “à part” qui font office de loi. Les
architectes entrent alors dans une démarche de co-construction en apportant/partageant ses
compétences d’architecte.
Voici le lien vers la présentation de Christine : https://bit.ly/2TBURTz
6. REX RENAULT DIGITAL (RD)
Floriane Wendling, Cloud Adoption Enabler chez D2SI
3 Phases de développement de l’entité autonome RD
■ Développement > démarche d’apprentissage
■ Intégration & procession de transformation du métier d’Ops. Objectif
: que tout le monde puisse délivrer les mêmes services > résilience
Comment ? Mise en place des méthodes de Dev / infra-as-code (peer programming, merge requests…) et
agiles. Le transfert de compétences s’est fait au fil de l’eau entre les membres de l’équipe ops et avec les
équipe de dev tout simplement en travaillant ensemble
■ Production > Passer de 10 projets en dev à 50 projets en prod
Comment ? Industrialisation / standardisation / Automatisation
Cela a permis de gagner en scalabilité, mais les interactions humaines elles ne sont pas scalables !
Besoin d’une nouvelle organisation pour passer à l’échelle > mise en place d’un support tournant (tout
le monde doit être capable d’accompagner les équipes projets tout en continuant en parallèle de développer la
plateforme Cloud)
7. Comment traiter le cas des architectes ?
○ Proposer des environnements de tests / lab sans contraintes techniques pour leur permettre
d’expérimenter des nouvelles solutions (monitoring, sécurité…)
○ Une fois la solution testée, l’équipe Ops la met en production et la propose en tant que
service à part entière aux équipes projets
Qui a la compétence support de l’infra ? Les Dev et les Ops ou uniquement les Ops ?
> Uniquement les Ops> question de sécurité des données > mais cette infra est pilotable via les APIs
Comment maîtriser le coût de chaque développement ?
○ Par la mise en place de métrique > alerting / monitoring pour piloter
Comment se passe la refacturation ?
○ Au forfait : coût de l’infra + licences des outils + accompagnement par l’équipe Ops
(consulting en quelques sorte)
Quid de la relation entre Renault Digital et Renault IT ?
○ Nouveau challenge pour RD : fusionner la DSI Cloud et la DSI traditionnelle
○ Standardisation > le pipeline de développement continu est le même sur le Cloud et sur
l’infra on-premise
○ Les équipes Ops RD et Renault IT ont les mêmes outils, les mêmes infras
○ Rapprochement des cultures et des mentalités Dev et Ops
○ Déployer l’agilité > faire intervenir les Product Owner au sein de Renault IT
8. Existe-t-il un kit de sensibilisation sur les nouvelles organisations chez Renault ?
○ Plutôt des outils : onboarding et formations
Comment faire avec les managers ?
○ Les orienter vers une posture de project leaders > changement de posture
○ Co-construction avec les équipes
○ Création de communauté / meetups internes
Pourquoi ne pas utiliser toutes les fonctionnalités de CloudWatch ?
○ Pour rester agnostiques, plusieurs cloud providers
Question RH > comment transformer les collaborateur·rices avec un mapping ancien ?
○ Les accompagner dans le recrutement
○ Ne pas leur demander de trouver le mouton à cinq pattes > former collectivement
● Comment passer de chef de projets à product owner ?
○ Former les RH pour qu’ils ou elles sortent de la fiche de poste et développent des notions de
rôle
> ALLER CHERCHER TOUS LES MÉTIERS
Pour en savoir plus sur le retour Renault Digital, c’est ici : https://bit.ly/2T64BAo
9. REX AIRBUS
Adrien Anceau - Product Owner, DevOps Platform
Un département entier dédié à la transformation
■ Sujets : Cloud, DevOps, monitoring, big data, IoT, IA à venir
■ 250 personnes (création en 2017 avec 30 personnes)
■ Rôle : identifier les différentes technologies à explorer
Une plateforme DevOps :
● Outils standardisés
● Promotion de la culture et du changement de process / méthode > interaction avec Airbus
● Visible niveau groupe
● Objectif : 15000 utilisateurs (dev) > les entités et filiales Airbus mais aussi les partenaires
Pourquoi cette plateforme ?
● Mise en place de Continuous Integration & Continuous Development / tests / automatisation
● Rationaliser / harmoniser les solutions DevOps déjà existantes
● Une solution uniforme pour les projets qui le souhaitent avec ses avantages : baisse des coûts,
partage de best practices, mutualisation & travail collectif
10. Comment constituer l’équipe ?
○ S’appuyer sur l’expertise de partenaires
○ Recrutement massif en externe (majorité) > volonté de changer la culture
○ Mobilité en interne
>>> Promouvoir le changement via la Diversité
Comment est perçu le département par Airbus groupe ?
○ Comme des perturbateurs par les fournisseurs de service
○ Extrêmement bien par les consommateurs de service
>>> Mais aujourd’hui les relations s’assainissent, le travail se fait en synergie
Le leader technique, quel est son rôle ?
○ Donner plus de libertés aux devs
○ Chaque projet a un compte de prod AWS et un kit d’outils de CI/CD > seul pré-requis : avoir la
compétence
○ En amont, l’équipe Cloud et DevOps accompagne et forme sur l’implémentation, ensuite
l’équipe fournit du support
Formation et parcours mis en place pour tous les métiers :
○ Training path pour évoluer d’un profil à un autre (ex : Ops vers DevOps)
○ Evolution de carrière pour celles et ceux qui le souhaitent
11. REX CONTINENTAL - BUSINESS PLATFORM
Olivier Flebus - Data Community Leader
Création d’une nouvelle entité juridique dédiée aux véhicules connectées > CDSF
■ Une entreprise plateforme avec un écosystème
■ Une entité business indépendante & autonome > pas une DSI !
>>>>> CULTURE DATA DRIVEN
Services rendus aux clients :
● Service Cloud pour les constructeurs automobiles
● Mobility-as-a-service pour les gestionnaires de flottes, uber….
Equipe :
● De 10 à 180 en 1 an > aujourd’hui : 200 personnes
● Multi-disciplinaire
● Mentalité “hackeurs” / système D
● L’équipe plateforme est owner du socle (l’équipe DevOps n’existe plus)
12. Run et exploration permanente
● Comment on amorce ?
● Comment faire du run et de l’exploration en même temps ?
Organisation de l’équipe :
● Squads (auto-organisées)
● Tribus (groupes de squads qui travaillent
ensemble)
● Chapters
● Création de communautés / de guildes
(cf. spotify) :
○ Transverses
○ Multi-compétences
○ Auto-organisées
Sens métier / temps long
13. Constitution et organisation équipe :
● Recrutements externes > pas toutes les compétences en interne
● Partager la connaissance > communautés
● Prévoir du temps pour les collaborateur·rices pour se former : training + MOOC
● 1 on-boarding par mois > toutes les nouvelles recrues arrivent le même jour
Organisation de Community Weeks
● 1 semaine toutes les 7 semaines
● Identifier des drivers produits
● Une fois la problématique identifiée > 1 semaine de task force pour travailler dessus
collectivement
● Plusieurs compétences réunies > équipe temporaire pendant 1 semaine (personnes de
différentes squads)
● Flying squads > faire venir pendant une semaine des expert·es sur un produit pour résoudre les
problèmes
● 20 % du temps dédié à ces Community Weeks (80% du temps dans la squad dédiée à un
produit)
>>> Apprentissage par l’expérimentation
14. Les sujets pour le prochain ?
CI / CD
SAFEOPS
DATA ET IA
Mise à disposition d'une landing zone
AWS
Lambda Coûts des solutions cloud
DATAOPS
Les problèmes pour changer les
pratiques
Problématiques de sécurité dans le
cloud
La data dans une DSI traditionnelle
15. On compte sur vous pour le prochain
TIAD Camp Toulouse ?
Le Bilan
Ca vous a plu ?