Décideurs it

Crédit Agricole GIP fiabilise ses infrastructures sans en limiter l’industrialisation

Par Bertrand Lemaire | Le | Cas d’usage

Crédit Agricole Group Infrastructure Platform a déployé Ansible Automation Platform de Red Hat pour industrialiser, fiabiliser et stabiliser ses infrastructures.

Pierre-François Liozon (à droite) et Florian Castagnet, CA-GIP - © CA-GIP
Pierre-François Liozon (à droite) et Florian Castagnet, CA-GIP - © CA-GIP

Créée le 1 er janvier 2019, Crédit Agricole Group Infrastructure Platform (CA-GIP) gère 80 % de la production informatique du groupe Crédit Agricole, et est au service des métiers du Groupe. CA-GIP a la responsabilité de l’intégration des applications et de leur mise en production. L’entreprise se situe au cœur des métiers technologiques : DevOps, Cloud Hybride, Digital Workplace, Cybersécurité, Télécommunications, Réseau… « Oui, nous utilisons l’approche DevOps » indique Pierre-François Liozon, responsable des équipes Unix de CA-GIP.

Issue du regroupement de plusieurs entités, CA-GIP était dotée d’une pluralité d’outils pour assurer l’orchestration et l’automatisation des infrastructures. Pierre-François Liozon relève : « l’infrastructure doit connaître une certaine stabilité pour que le monde applicatif par-dessus puisse vivre sa vie de manière agile. »

Garantir le maintien en conditions opérationnelles

L’infrastructure doit connaître une certaine stabilité pour que le monde applicatif par dessus puisse vivre sa vie agile.

« De très fortes attentes de nos clients conjuguées à notre souhait de proposer une offre de services toujours plus compétitive nous a obligé à remettre en question notre outillage. » poursuit-il. Il fallait donc choisir entre Ansible Automation Platform (AAP) de Red Hat, un outil libre, ou bien HPSA qui est un logiciel propriétaire. Comme les serveurs Linux de CA-GIP sont en grande partie sous un Linux de Red Hat, CA-GIP a opté pour Ansible Automation Platform (AAP) du même éditeur. Au-delà des 30 000 nœuds (à terme : 60 000) à gérer, AAP gère également des équipements réseau et des serveurs Windows. « Cette capacité à l’universalité a aussi été un critère du choix fait » ajoute Pierre-François Liozon.

Le choix d’AAP multipliait donc les avantages. Cette version stabilisée et certifiée par Red Hat d’AWX permettait de libérer du temps aux équipes CA-GIP qui n’avaient plus à assurer elles-mêmes le suivi des versions et le contrôle des non-régressions. Et CA-GIP homogénéisait aussi son approche en adoptant « Ansible du sol au plafond ». Les équipes hors administration des serveurs ont aussi apprécié cette universalité et ont donc adopté la plateforme progressivement.

Le temps, c’est de l’efficacité

Si nous mettons une barrière à un développeur, nous lui donnons aussi une solution

En libérant du temps aux équipes, le choix d’AAP a permis à celles-ci de consacrer davantage de temps à l’accompagnement du déploiement en travaillant conjointement avec les développeurs. Pierre-François Liozon précise : « auparavant, nous passions trop de temps à maintenir l’infrastructure et, ensuite, nous poussions une boîte noire aux développeurs en les laissant se débrouiller, ce qui frustrait les deux côtés. Aujourd’hui, nous n’avons plus ces frustrations, nous passons moins de temps à maintenir l’infrastructure et plus à accompagner les développeurs. »

Les équipes infrastructure posent donc un cadre afin de garantir la stabilité des infrastructures et la qualité de service induite. « Si nous mettons une barrière à un développeur, nous lui donnons une solution » relève Pierre-François Liozon. L’approche avec AAP permet d’imposer, par exemple, aux développeurs de passer par les API pour réaliser les tâches nécessaires (par exemple créer un système de fichiers) au lieu de disposer de droits étendus. Florian Castagnet, ingénieur Infrastructure technique de CA-GIP, observe : « c’est un peu de technique et beaucoup d’accompagnement des développeurs pour changer leurs méthodes de travail. »

Une approche plus sûre

Lorsque les développeurs utilisent des conteneurs et des plates-formes de type Kubernetes / Openshift, ils peuvent disposer de davantage de droits. « Mais migrer le patrimoine applicatif dans une architecture à base de conteneurs n’a aucun modèle économique » pointe Pierre-François Liozon. Par conséquent, la migration sera progressive, au fil des renouvellements applicatifs, même si du « lift & shift » vers du conteneur permettrait d’aller plus vite. Pour l’heure, l’essentiel est en architecture classique, à base de serveurs, donc avec des restrictions de droits.

Du coup, la cybersécurité est plus facilement garantie. Si un développeur possède des droits étendus d’administration, il peut modifier des configurations systèmes. Et avec les automatisations, un accident peut arriver avec des reconfigurations de centaines ou milliers de serveurs par erreur… Les choix opérés, notamment AAP, par CA-GIP facilitent donc la conformité. Pierre-François Liozon se réjouit : « nous avons suffisamment industrialisé nos tâches pour avoir la bande passante nécessaire pour tout réaliser ».

(Article revu par le service communication du Crédit Agricole)

Transférer cet article à un(e) ami(e)