Le document présente les offres et services d'Eleven Labs, soulignant le concept de 'platform engineering' comme solution pour améliorer l'autonomie des équipes de développeurs tout en réduisant la complexité des infrastructures. Il explore également des exemples de mise en œuvre de plateformes de développeurs internes dans différentes structures, allant des PME aux grandes entreprises, et discute des défis et des meilleures pratiques associés à ce processus. Enfin, le document aborde l'importance de comprendre les besoins réels des utilisateurs et d'anticiper les évolutions technologiques lors de la conception de telles plateformes.

1. ELEVEN LABS, C’EST ?
1
12 100
15 M€ 50+
ans d’existence de la
fusée elevenienne
astronautes
actuellement dans la
fusée
de chiffres d’affaires
clients de tous
secteurs : média, e-
commerce, presse,
banque…
PARIS
102 rue du
Faubourg
Saint-Honoré
75008 Paris
France
NANTES
40, rue la Tour
d'Auvergne
44200 Nantes
France
MONTRÉAL
1155, Metcalfe St
Suite 1500
Montréal, QC H3B
2V
Canada
7 OFFRES DE SERVICES
Développement
web & mobile
DevOps &
adaptation
continue du SI
Data
Management
Stratégie et
Pilotage Produit
Design & User
Experience
Architecture
SI & Data
Coaching
Agile

2. UX Design 101
Introduction à l’UX Design
Platform Engineering :
La grande réponse à la vie,
l’univers, et tout le reste

3. Qui suis-je ?
DevOps / Platform Engineer @ Eleven Labs
graillus
𝕏 @grailloute
Robin Graillon

4. Un peu d’histoire

5. Il y a fort longtemps…

6. DevOps à la rescousse !

7. DevOps

8. Mais il y a un couac

9. DevOps : The new Full Stack

10. Ça ne va pas en s’arrangeant…

12. L’utopie DevOps

13. DevOps : Le bilan
● Les équipes sont plus autonomes
Mais :
● Elles ont mal à maîtriser le nombre grandissant de technologies
● Augmentation exponentielle de l’entropie
● Sécurité : modèle du “least privilege” compromis
● Le DevOps est souvent mal implémenté

14. Platform Engineering
L’ultime solution ?

15. Objectifs du Platform
Engineering
● Rendre les équipes de développeurs autonomes (You build it, you ship it, you run it)
● Limiter la charge mentale liée à la multiplication des technos
● Limiter les dépendances inter-équipes
● Normaliser, standardiser les pratiques
● Garantir l’application des règles de sécurité

16. Internal Developer Platform
● Une plateforme en temps que service (PaaS) interne
● Pensée comme un vrai produit sur mesure
● Point d’entrée unique où sont disponibles toutes les infos (docs, statut des services, etc.)
● Couche d’abstraction pour masquer la complexité de l’infrastructure
● Répond aux besoins des équipes en utilisant les standards de l’entreprise (conventions,
sécu, etc.)

17. Internal Developer Platform

18. Self-service
INTERNAL
DEVELOPER
PLATFORM
VM Instance
Database
DNS
Kubernetes
CRD
Container
Registry
CI/CD Pipeline
Développeurs
Test Environnement
Application Astro
“J’ai besoin d’un
environnement de test pour
mon application Astro
Délivre un
environnement

19. Service Catalog

20. En résumé
Côté équipes produit :
● Meilleure autonomie
● Plus besoin d’expertise sur les détails d’implémentation de l’infra
● Plus besoin d’accès administrateur sur les ressources de l’infra
Côté équipes infra :
● Meilleur contrôle des implémentations = uniformisation
● L’infrastructure peut être remaniée sans casser le contrat d’interface
● Centralisation des compétences SecOps/FinOps
● Mutualisation des ressources

21. Platform Engineering :
Oui, mais…

22. Platform Engineering :
Oui, mais…
● Concevoir, développer et maintenir la plateforme a un coût
● Ce surcoût est-il toujours justifié, même pour une structure de taille
modeste ?
● Le cas échéant, puis-je adapter les pratiques à mon organisation ?

23. Oui, le Platform
Engineering peut s’adapter
à toutes les structures

24. Infra
Plan
et
Dev
Mo
on
Dev
Moo
n
Exemple 1 :
Système Planétaire
Type : PME/Startup (moins de 50 techs)
Contraintes :
● Peu de ressources disponibles
● Pas assez de budget pour équipe
plateforme dédiée

25. Ce qui compte
● Un point d’entrée unique, pour tous
● Documentation facile à trouver, et à jour !
● La “plateforme” devient le réflexe de tout le monde (consultation +
contribution)

26. Internal Developer Platform
Starter Pack
Support : Confluence, Notion, Mkdocs
Contenu :
● Documentation
○ Procédures courantes
○ Best Practices
○ Troubleshooting, Runbooks
● Recensement des apps et leurs URLs par environnement
● Liens utiles (outils, repository de templates)
Templates :
● Modules Terraform
● Templates de pipelines CI/CD
Services:
● Pipelines/Workflows en libre service

27. Infra
Star
Prod
uct
Team
Platfo
rm
Team
Exemple 2 :
Système Solaire
Type : Entreprise moyenne à grosse / ScaleUp
(50 à 500 techs)
● Plusieurs équipes infra : Core, Data,
Cloud
● Équipes produit plus nombreuses
Contraintes:
● Responsabilités réparties sur plusieurs
équipes
● Budget plateforme limité
Prod
uct
Team

28. Platform Team dédiée

29. Internal Developer Platform
Support : SaaS (Port) ou Self-hosted (Backstage)
Contenu :
● Catalogue de services
● État de mes services
● Déploiements/configuration
Templates :
● Templates de repositories
● Charts Helm
● Libs
Services:
● Storage bucket
● Secret Management
API:
● Interface “click click”

30. Infra
Black
Hole
Prod
uct
Team
Platfo
rm
Team
Exemple 3 :
Galaxie
Type : Très Grosse Structure (500+ techs)
● Communication très difficile (ticketing)
● Dépendances entre équipes infra
● Grande diversité des services
Prod
uct
Tea
m
Platfo
rm
Team
Infra
Team
Platfo
rm
Team
Infra
Team
Prod
uct
Team
Prod
uct
Team
Prod
uct
Team
Prod
uct
Tea
m
Prod
uct
Prod
uct
Team
Prod
uct
Tea
m
P
u
T

31. Organisation

32. Internal Developer Platform :
Modèle haut de gamme
Support : Backstage ou recette maison
● Interface 100% sur mesure
● Chaque platform team intègre son module
Services:
● VMs, K8S Clusters
● Plusieurs niveaux de HA
API :
● APIs REST
● CLIs
● Libs
● Modules Terraform (pour l’API)

33. Ce qu’il faut retenir
Faites en fonction de vos moyens, l’idéal reste le même
Le Platform Engineering c’est avant tout un changement de mentalité et
d’organisation
Particulièrement pertinent dans les moyennes et grosses structures

34. REX: Conception d’une
plateforme évolutive
basée sur des Contrôleurs
Kubernetes

35. Le contexte
● Un grand groupe international (secteur financier)
● 100+ Dev teams réparties dans 4 Time Zones
● Gestion d’un parc de 500+ clusters Kubernetes dans le cloud
● 4000+ Requêtes de support par an
● 4 ingénieurs dédiés au support

36. Situation initiale

37. Première tentative

38. Leçons
● Besoin mal compris dès le départ
● Manque de feedback temps réel aux utilisateurs
● Techniquement pas fiable
● Utilisateurs perdus en cas de problème

39. La nouvelle cible

40. Comment on s’y est pris

41. L’équipage de choc
● 1 Product Manager : Vision produit
● Développeurs Front End : Développement du portail en React
● Platform Engineers : Conception et implémentation de la plateforme

42. Récolte des besoins
● Étape la plus importante
● Aller auprès des équipes
● Analyse des tickets de support récurrents
● Aller chercher dans l’historique des mails
● Ce qui nous prend trop de temps au quotidien et
qui doit être automatisé

43. Conception du produit
● Conception pour avec les équipes, définition de l’API
● Expérience utilisateur : simplicité, efficacité
● Fait pour durer : robuste et maintenable dans le temps
● Évolutif : Anticiper les changements de technos ou d’organisation
● Rester pragmatique : ne pas mettre la barre trop haut

44. Planification
● Découper en fonctionnalités
● Ne pas tenter de livrer tout d’un coup
● Prioriser les “quick wins”
● Focus sur les fonctionnalités à forte valeur ajoutée
● Roadmap

45. Conception Technique
Nos contraintes :
● Rétrocompatible avec l'infrastructure existante
● Ne pas bloquer la gestion du parc legacy
● Se concentrer sur la valeur : Ne pas réinventer la roue
Bonus :
● API Orientée état
● Architecture modulaire pour pouvoir travailler à plusieurs équipes

46. Architecture cible

47. Pourquoi pas Kubernetes ?
"Kubernetes is a platform to build platforms" - Kelsey Hightower

48. Kubernetes

49. Un modèle déclaratif

50. Une API extensible
● Déclarer facilement nos propres ressources d’API avec
CustomResourceDefinitions (CRDs)
● Implémenter nos propres contrôleurs avec notre logique
métier
● Auto-découverte des CRDs installées dans le cluster
● Interopérabilité (OpenAPI v3 schema)

52. Un écosystème riche
● Outillage plug & play: ArgoCD, Crossplane, etc.
● Libs disponibles dans les principaux langages (Python, Go, Java, etc.)
● Frameworks: controller-runtime, operator SDK

53. Et aussi
● Gestion des permissions fine (RBAC)
● Multi-tenancy (Namespaces)
● Admission Webhooks : validation & mutation
● Monitoring (stack Prometheus)

54. Architecture controleurs

55. Comment implémenter un
contrôleur ?
(et c’est pas si compliqué)

56. Operator SDK
● Génère le code boilerplate de l’opérateur
● Génère les CustomResourceDefinitions
● Génère les manifests pour déployer

57. Implementation des CRD
● Compléter les types pré-générés
● Gestion de la validation via annotations
● Génération des CRDs via simple
commande

58. ● Plus qu’à ajouter la logique métier
● Écosystème Go très complet sur l’outillage DevOps
● Gestion d’erreurs : Requeue, Status Conditions
● On oublie pas les tests unitaires à compléter
Implementation du controleur

59. Résultat

60. Rappel des étapes de
développement
● Implémenter le code
● Tests
● Documentation
● Tests
●Tests
●DOCUMENTATION

61. Déploiement
● Communication
● Rollout progressif / Double run
● Monitoring
● Rollback en cas de problème

62. Recommencer
● Iterations rapides
● Récolter du feedback en continu
● Ressenti des équipes > métriques techniques pures
● Communication nouvelles releases

63. Bilan

64. Résultats (attendus)
● Moins de demandes de support
● Plus de temps passé sur des nouvelles fonctionnalités
● Nos services sont utilisés (moins de shadow IT)
● Nos utilisateurs sont contents
● Nos utilisateurs se contentent des permissions read-only sur l’infra

65. Challenges rencontrés
● Comprendre les vrais besoins
● Gestion du parc existant (rétrocompatibilité)
● Gestion du drift
● Éviter les abstractions mal faites
● Ne pas casser le contrat d’API

66. Pro Tips
● Utiliser des outils et pratiques standard
● Avoir un dev senior dans l’équipe
● Versioning / Release management
● Ne négligez pas le monitoring

67. La suite
● Implémenter d’autres contrôleurs
● GitOps
● Remplacer Terraform par Crossplane ?
● Résilience : que se passe-t-il en cas de perte du control plane ?
● Gouvernance : qui est responsable du cluster de Management ?

68. Questions ?

69. Merci !