« Notre cœur de métier est de produire du code »

Intervenu au sein de notre matinale DevOps du 23 septembre dernier, Olivier Heitz détaille l’organisation et la démarche qui permettent à ses équipes de répondre plus vite et de manière plus efficace aux besoins des métiers.

Entretien avec Olivier Heitz, DSI de Bouygues Telecom

Pouvez-vous nous rappeler les contours de la DSI de Bouygues Telecom et son périmètre d’action ?

La DSI de Bouygues Telecom, ce sont environ 600 collaborateurs internes et à peu près le même volume en prestation. Notre activité est tournée à 60 % vers les projets, qu’il s’agisse de développer de nouveaux services pour nos métiers ou de nouvelles offres, et à 40 % vers le run. Nous gérons à peu près 300 applications.

En matière d’organisation, nous avons deux grosses usines de développement, l’une orientée back-office, l’autre front-office. Au sein de ces deux « paquebots », nous avons des plus petites usines de taille variable, typiquement entre 8 et 50 personnes, qui travaillent sur des objets particuliers du SI. Ce peuvent être des objets fonctionnels comme techniques, certains liés aux fonctions support, aux outils de vente, etc., ou à nos prestations de services en tant qu’opérateur.

Dans quelle mesure la DSI de Bouygues Telecom privilégie-t-elle le développement interne ?

Nous avons à peu près 60 % de fait-maison et 40 % de progiciels. Pour les sujets assez classiques où nous n’avons pas de posture concurrentielle – les RH, la compta, le CRM… –, c’est plutôt du progiciel. Ainsi, nous utilisons du SAP pour la gestion des ressources humaines, des stocks et pour la compta, du Salesforce pour le CRM, du Genesys pour la distribution des appels en centre de contacts, du ServiceNow pour le suivi des incidents de nos clients, ou encore Netcraker avec le moteur Geneva pour la facturation grand public.

Sur la plupart des autres sujets, c’est du home-made. Par exemple, sur la valorisation temps réel de l’usage du réseau, la capacité de le faire de façon efficace, avec un grand nombre de paramétrages possibles, joue sur notre capacité à proposer des offres innovantes. Cela est donc justifié de le réaliser en interne. Plus globalement, je considère que notre cœur de métier, à la DSI, c’est de produire du code. Cela devient de plus en plus un asset et c’est plutôt bien pour les DSI, car on fait ainsi partie des investissements de l’entreprise. On n’est plus seulement considérés comme un centre de coûts.

Comment cette stratégie influe-t-elle sur le staffing de la DSI ?

Historiquement, nous avons toujours été une DSI qui a souhaité maîtriser non seulement le fonctionnel, mais aussi la technologie des composants. Nous avons ainsi toujours conservé des équipes de développement assez étoffées en interne, même dans les phases où tout le monde disait qu’il fallait passer en masse à l’offshore. Nous avons créé un centre de développement interne à Nantes et, depuis cinq ans, percée du digital aidant, cela s’est accéléré. De fait, nous avons renforcé nos équipes avec des développeurs et des tech leads, des gens qui maîtrisent vraiment le code. Mais je considère que nous ne sommes pas encore au niveau optimal.

Je m’implique donc beaucoup au niveau des recrutements, notamment pour montrer la palette de technologies que nous utilisons, les périmètres fonctionnels que nous offrons. Bien sûr nous avons des systèmes de télécommunications, mais nous avons aussi une activité de retailer avec 500 points de vente, avec également des problématiques de logistique et de SAV. Nous avons des applications mobiles, et un site web qui fait 14 millions de vues par mois. Cette activité web occupe d’ailleurs près de 120 personnes. Et j’ai aussi une équipe de près de 20 personnes qui fait de l’intelligence artificielle. Peu de DSI offrent autant de diversité. À cela s’ajoute la démarche ByTech du groupe Bouygues qui a également vocation à faciliter la mobilité entre les DSI de ses différentes filiales.

Une récente étude menée par Ausy, Randstad et Infopro Digital montre que les étudiants ingénieurs sont particulièrement sensibles à la question du réchauffement climatique. Est-ce une préoccupation au sein de votre DSI ?

Nous avons un plan global de RSE au sein de l’entreprise, avec notamment la volonté de diminuer notre empreinte carbone. Cela touche forcément l’IT. De fait, par rapport aux pratiques précédentes, nous avons décidé de garder les PC un an de plus. Nous avons également travaillé sur nos datacenters et rénové ceux qui n’étaient pas dans la norme.

La question du télétravail n’est pas neutre, non plus, car chaque jour – hors période actuelle –, ce sont près de 1 200 personnes de la DSI qui viennent au Technopole de Meudon, principalement en voiture. On travaille donc à le généraliser deux jours par semaine, mais sa mise en pratique nécessite une adaptation des pratiques et de l’organisation du travail. Nous pouvons aussi nous améliorer sur l’écoconception des logiciels : nous avons fait de la sensibilisation, nos architectes ont eu une formation, mais son opérationnalisation est un peu compliquée et nous ne sommes pas à la pointe sur le sujet.

Avant de pouvoir solliciter de nouvelles ressources, comment vous assurez-vous déjà que vos équipes sont suffisamment productives ?

Dans certaines industries, dans certains domaines, la productivité est assez facile à mesurer et à comparer à des valeurs moyennes, voire standards.
En termes de production de lignes de code, nous n’avons pas encore trouvé le ou les bons indicateurs. Il y a certes les points de fonction, mais c’est assez consommateur de ressources. Nous avons fait l’effort durant quelques années, puis avons stoppé la démarche. Il faut donc prendre le problème autrement. Par exemple, là où je me fais challenger, c’est quand je dois livrer une fonctionnalité : en combien de temps suis-je capable de la réaliser et de la mettre en production, et est-ce que ce délai est le plus court possible ?

Pour améliorer mon time-to-market, je dois donc m’assurer que nous industrialisons le plus possible la production de code et que celui-ci est le plus efficace possible.

En quoi consiste la démarche que vous avez mise au point ?

D’abord, nous avons industrialisé la production du code qui n’a pas de valeur fonctionnelle. Les traitements de logs, les fonctions de reprise, de scalabilité, etc. : nous avons créé un ensemble d’API que les développeurs utilisent sans plus se poser de questions, pour porter une énergie maximale sur les fonctionnalités et sur les tests.

Ces tests, nous les avons aussi en partie automatisés. Avant, ils pouvaient représenter 30 % du temps d’un sprint. Ce temps a été divisé par deux, ce pendant que la couverture de test a été doublée. C’est assez long à réaliser. Pour le moment, 30 % de notre périmètre de test est automatisé et nous pensons atteindre les 100 % d’ici un an et demi sur les tests de non régression. Mais c’est un investissement payant, car en sortie on a une qualité de code bien meilleure.

Vous avez également automatisé la mise en production ?

Oui, car en même temps qu’on se lançait dans l’agilité, on s’est aperçu qu’on passait beaucoup de temps sur les déploiements d’applications dans les différents environnements. Au début, on a laissé de l’autonomie aux équipes pour tester des outils ou les concevoir. Le mouvement s’est accéléré il y a à peu près trois ans, quand nous avons démarré un projet structurant de migration vers le cloud. Pour profiter à fond de cet environnement, il est en effet quasiment impératif de se doter d’une chaîne automatisée de CI/CD (Intégration continue, Déploiement continu). Actuellement, nous sommes dans une étape d’uniformisation. Nous avons donc une chaîne DevOps complète et commune, et toutes nos usines de développement y vont progressivement.

Aux gains de temps et de qualité s’ajoute ainsi un troisième avantage : une mobilité facilitée pour nos collaborateurs au sein de la DSI. Ils peuvent changer de domaine fonctionnel, de technologie de développement, ils auront toujours le même tronc commun et seront opérationnels rapidement.

Quelle gouvernance avez-vous définie pour cette chaîne DevOps ?

Passées les premières initiatives, on s’est aperçu que, pour passer à l’échelle, il fallait une équipe dédiée, à la fois pour maintenir cette chaîne CI/CD, mais aussi pour porter assistance aux usines de développement dans leur adoption de la démarche et des outils. Nous avons donc regroupé les personnes qui avaient montré une forte compétence sur le sujet dans une entité intégrée à celle qui gère le cloud au sein de la production. Cela permet à cette équipe d’être transversale par rapport aux usines de développement, qui peuvent faire des apports et proposer par exemple des API qu’elle intégrera à notre socle de référence.

Au-delà de cette entité, nous avons réuni d’autres éléments importants pour assurer la réussite de notre démarche : une position et un sponsoring très forts de la DSI – nous assistons systématiquement, mes N-1 et moi, au comité de pilotage mensuel –, ainsi que la bienveillance nécessaire pour laisser le temps aux collaborateurs de s’y mettre à leur vitesse.

Quel est le niveau d’avancement de votre migration vers le cloud ?

Aujourd’hui, 40 % de notre système d’information repose sur des composants faits-maison qui sont dans le cloud. Nous ne l’avons pas fait pour économiser de l’argent.
Pour des structures de notre taille, cela ne coûte pas moins cher que d’être en interne. L’intérêt se situe au niveau de la maturité en termes de sécurité, de scalabilité et de haute disponibilité, qu’il serait difficile d’atteindre avec une équipe interne de la taille de la nôtre.
C’est un peu le même débat que pour le SaaS : cela coûte un peu plus cher, mais c’est impressionnant en termes de capacité à mettre en œuvre et d’évolutivité. Quand nous avons remplacé Siebel par Salesforce, sept mois ont suffi entre la signature et la bascule de nos 6 000 conseillers de clientèle. Et les évolutions qui sont livrées tous les trois mois sont directement exploitables par nos métiers. Cela a une vraie valeur.

Pour en revenir au cloud, c’est celui d’AWS que nous utilisons. Nous allons prochainement faire le bilan de ces trois dernières années pour déterminer s’il s’agit ou non d’aller plus loin que les 40 % actuels. Si la réponse est oui, nous chercherons à avoir un second partenaire, pour ne pas avoir tous nos œufs dans le même panier.

Propos recueillis par Pierre Landry.
Photos de Maÿlis Devaux.

---

PARCOURS D’OLIVIER HEITZ

2013-2018 : Directeur du SI front-office, digital et retail, Bouygues Telecom
2006-2013 : Directeur des opérations et de l’infrastructure IT, Bouygues Telecom
2000-2006 : Responsable de développement du domaine Network Provider, Bouygues Telecom
1991-1998 : Chef du Service informatique, Wolters Kluwer CA
1989-1991 : Responsable des développements, Institut Technique pour l’Étude du Médicament

FORMATION
   2014 : MBA, HEC
   1997 : DESS systèmes d’information, IAE de Paris
   1989 : Licence de management en supply chain, IECS de Strasbourg
   1988 : DUT informatique de gestion, IUT de Strasbourg

---