Alternance : Crédit Agricole Technologies & Services

J'ai abordé cette SAE avec un état d'esprit particulier : il s'agissait de me préparer à une réalité que je n'avais pas encore vécue. La collecte de missions, la veille technologique et le POC ont tous été réalisés avant ma première période en entreprise, avec pour objectif de ne pas arriver les mains vides dans un environnement que je connaissais à peine. Ce contexte a orienté toutes mes décisions : j'ai choisi de ne pas traiter un sujet générique, mais de cadrer mon travail autour des technologies que j'allais effectivement utiliser chez Crédit Agricole Technologies et Services.

La première décision a été de choisir l'écosystème Java comme fil directeur. Ce n'était pas une évidence : mon expérience personnelle en développement web est principalement construite sur JavaScript et TypeScript, avec des frameworks comme Deno ou Node.js. Java m'était familier comme langage de cours, mais jamais dans un contexte professionnel back-end. J'ai donc commencé par la collecte de missions, qui m'a permis de formaliser ce que je comprenais de mon futur rôle et d'identifier les technologies sur lesquelles me concentrer.

Pour la veille, j'ai choisi un angle comparatif : pourquoi Java Spring Boot plutôt qu'un autre écosystème back-end ? Je voulais comprendre la logique derrière l'utilisation de Spring Boot dans un contexte bancaire, pas simplement apprendre à l'utiliser. Analyser les alternatives, .NET Core, Node.js, Go, les architectures monolithiques legacy, m'a permis de construire une compréhension argumentée plutôt qu'une simple liste de fonctionnalités. Le POC a ensuite servi de validation pratique : tester par moi-même que les conclusions de ma veille correspondaient à une réalité tangible.

L'ensemble de ce travail a été conduit de façon totalement autonome, sans binôme ni équipe. Ce n'est pas une situation que j'ai trouvée difficile en soi, car j'ai l'habitude de travailler seul sur des projets personnels, mais elle m'a imposé une discipline différente : aucun regard extérieur pour valider mes choix, aucune discussion pour tester mes raisonnements. J'ai dû apprendre à m'auto-évaluer avec rigueur, notamment sur la partie comparative de la veille, où il était facile de pencher vers une conclusion préconçue.

Le cours d'analyse (R3.03) a fourni les outils méthodologiques les plus directement mobilisés dans ce travail : structurer une comparaison, identifier des critères pertinents, distinguer ce qui relève de la mesure objective et ce qui relève du contexte. La veille n'est pas un simple inventaire de technologies, c'est un raisonnement argumenté. Apprendre à modéliser des besoins et à formuler des cas d'usage m'a appris à poser les bonnes questions avant de chercher les réponses.

Le cours de communication professionnelle (R3.13) a orienté la façon dont j'ai structuré et rédigé les livrables, en particulier le rapport de veille. Synthétiser cinq écosystèmes dans un document lisible demande un effort de mise en forme que la rédaction technique standard ne prépare pas toujours bien. La capacité à construire un tableau de synthèse exploitable, à hiérarchiser l'information et à conclure de façon claire et directe est une compétence en soi.

Pour le POC, le cours de qualité de développement (R3.04) a fourni le cadre de structuration du code : séparation des responsabilités, gestion des erreurs, écriture de tests. Le cours d'architecture logicielle (R4.01) a éclairé le pattern MVC appliqué dans l'organisation Controller/Service/Model de l'API. Avoir abordé ces notions dans d'autres langages et frameworks à l'IUT m'a aidé à les transposer à Spring Boot plus rapidement que si je les avais découvertes de zéro.

Enfin, le cours de projet personnel et professionnel (R3.14) a joué un rôle moins visible mais réel : il m'a aidé à comprendre pourquoi s'investir dans une veille avant même d'arriver en entreprise n'est pas un exercice purement scolaire, mais une posture professionnelle à construire le plus tôt possible.

Les trois livrables couvrent des apprentissages issus de cinq des six compétences du BUT, et c'est leur articulation qui rend cette SAE représentative d'une démarche professionnelle complète.

La collecte de missions mobilise les apprentissages liés à la compréhension d'une organisation et à la conduite d'une mission. AC26.01 (Comprendre la diversité, la structure et la dimension de l'informatique dans une organisation) : analyser la structure de CA-TS, ses équipes spécialisées, ses rôles et ses interactions m'a permis de formaliser un contexte professionnel que je n'avais pas encore vécu. AC25.01 et AC25.02 (Identifier les processus d'une organisation et formaliser les besoins) : identifier les missions de l'équipe Paiement Mobile, ses contraintes de sécurité et de disponibilité, et en déduire les compétences attendues est directement ce que ces apprentissages visent. AC26.04 (Rendre compte de son activité professionnelle) : le livrable lui-même, structuré et documenté, est une forme de compte rendu professionnel.

Le rapport de veille technologique couvre les apprentissages liés à l'évaluation et au choix des solutions. AC25.03 (Identifier les critères de faisabilité d'un projet informatique) : comparer cinq écosystèmes selon des critères mesurables et contextualisés au secteur bancaire est précisément l'exercice de faisabilité que cet apprentissage vise. AC22.03 et AC22.04 (Comprendre les enjeux de sécurisation et évaluer l'impact des solutions) : la veille intègre systématiquement la dimension sécurité dans la comparaison, Spring Security étant un argument décisif dans le contexte d'une application de paiements. La comparaison des performances et de la consommation de ressources entre les différents écosystèmes témoigne d'une évaluation consciente de l'impact réel des choix technologiques.

Le rapport de POC couvre les apprentissages liés au développement et à la validation. AC21.01 et AC21.03 (Implémenter les spécifications et adopter de bonnes pratiques de conception et de programmation) : l'API TODO structurée en couches Controller/Service/Model avec gestion centralisée des exceptions prouve la capacité à implémenter des spécifications REST de façon professionnelle. AC21.04 (Vérifier et valider la qualité de l'application par les tests) : les tests Postman documentant les cas nominaux et les cas d'erreur constituent une démarche explicite de validation. AC23.01 (Concevoir et développer des applications communicantes) : le POC est une application communicante REST exposant des endpoints HTTP standardisés, ce qui correspond directement à cet apprentissage.

Le principal biais de cette SAE est chronologique : j'ai fait ma veille avant d'avoir vécu ce dont je parlais. Les conclusions du rapport sont correctes, Java Spring Boot est bien le choix adapté pour un contexte bancaire, mais elles reposaient sur de la littérature et des benchmarks, pas sur une expérience directe. Certains éléments que j'avais rédigés avec un certain flou, notamment autour de l'intégration avec les systèmes legacy et de la complexité de la mise en production, ont pris un sens très différent une fois que j'ai vu en pratique ce que cela représentait concrètement.

Le POC lui-même est intentionnellement limité. J'ai choisi un stockage en mémoire pour rester concentré sur les patterns Spring Boot sans complexifier avec une base de données. C'était le bon choix pédagogique à ce stade, mais c'est aussi ce qui donne au projet un caractère assez élémentaire. Une base de données relationnelle, une couche de sécurité Spring Security, des tests unitaires automatisés : ce sont les dimensions que j'ai abordées réellement seulement plusieurs mois plus tard, en entreprise. Je savais qu'elles manquaient, j'en parle moi-même en conclusion du rapport de POC, mais je n'étais pas en capacité de les implémenter correctement à ce moment-là.

Si c'était à refaire, je réduirais la part tutorielle et je consacrerais plus de temps à un projet légèrement plus ambitieux, même imparfait. Suivre des formations en ligne produit une compréhension guidée : on comprend ce qu'on fait parce qu'on suit des étapes, pas nécessairement parce qu'on a résolu un problème par soi-même. C'est en butant sur de vraies questions, sans la réponse disponible dans la vidéo suivante, qu'on construit une compréhension plus solide. J'aurais pu me créer délibérément ce type de friction dès la phase de POC, au lieu d'attendre l'entreprise pour la vivre.

Dès les premières semaines, j'ai adopté une démarche systématique face à chaque nouveau ticket : analyser l'impact potentiel sur les autres ressources de l'équipe avant d'écrire une ligne de code, tester localement, valider avec Johnatan avant de passer à l'étape suivante dans le workflow GitLab, et laisser un point d'avancement écrit à chaque départ en période école pour ne pas bloquer l'équipe pendant mon absence. Cette organisation que je me suis imposée dès le départ était aussi une façon de gérer mon niveau d'autonomie réel, encore limité : elle me permettait de progresser sans créer de dépendance sur des sujets en cours.

Au fil des périodes, les allers-retours de correction se sont réduits : je m'appropriais progressivement l'environnement et les attentes de qualité de l'équipe. La deuxième période en entreprise, en février, a été celle où je me suis impliqué sur des sujets plus exigeants : analyses d'impact inter-services, rédaction de RFC, remédiation de CVE. Prendre en charge ces sujets alors que je n'étais pas encore complètement à l'aise avec l'architecture était un choix d'implication délibéré. J'aurais pu rester sur des tickets plus simples : j'ai préféré me confronter à ce que je ne maîtrisais pas encore, en m'appuyant sur Johnatan comme filet de sécurité sans pour autant lui déléguer la réflexion.

À partir d'avril, j'ai pris plusieurs décisions d'implication allant au-delà de ce qui m'était attribué. J'ai choisi de contribuer à la documentation SharePoint en profitant du regard neuf que j'avais encore sur l'environnement. Quand Oumayma a été absente pour arrêt de travail, je me suis proposé pour assurer la continuité de ses réunions techniques et de son sujet prioritaire dans le sprint. Pour le Spring Batch, j'ai organisé moi-même les points de cadrage avec les architectes et les DBA sans attendre qu'ils soient planifiés pour moi. En parallèle, j'ai mené une démarche de réseau professionnel pour ma recherche d'alternance en vue de l'ENSIBS : prises de contact avec des personnes stratégiques en interne, recommandation sollicitée auprès de mon maître d'alternance, élargissement progressif du périmètre de recherche quand les pistes initiales n'ont pas abouti.

Ce que je retiens avant tout de cette année, c'est un changement de posture. En début d'alternance, je cherchais avant tout à m'intégrer sans freiner l'équipe. En fin d'année, je cherche à faire avancer les choses au-delà de ce qu'on m'a demandé. Cette progression ne s'est pas décidée un matin : elle s'est construite ticket après ticket, période après période, à mesure que la confiance s'est installée.

Le cours de management des systèmes d'information (R3.10) a été l'une des ressources les plus transférables à l'alternance. Comprendre comment s'organise une équipe informatique, les flux de décision, les rituels de pilotage de projet et les processus de gouvernance m'a donné un cadre pour interpréter ce que je vivais dans la Squad. Assister à un Sprint Planning ou à une rétrospective en ayant vu ces concepts en cours, même schématiquement, accélère la compréhension de ce qui se joue réellement dans la salle. Le management avancé des SI (R4.B.09) a approfondi ces notions de gouvernance en S4, au moment même où je participais à la structuration interne d'une équipe encore jeune chez CA-TS.

La communication professionnelle (R3.13) et la communication interne (R4.06) ont directement alimenté la façon dont je rends compte de mon travail, que ce soit dans mes tableaux de bord bimensuels ou dans les échanges quotidiens avec l'équipe. Savoir rédiger une RFC, structurer un compte rendu d'analyse d'impact, présenter un état d'avancement en Daily sans surcharger le propos : ces compétences paraissent anodines, mais elles ont un impact direct sur la façon dont on est perçu dans une équipe professionnelle.

Sur le plan technique, la cryptographie et sécurité (R3.09, R4.B.10) et les modules de cybersécurité (AL3.B.01, AL4.B.01) ont fourni les bases pour aborder les missions de remédiation de CVE avec du recul. Analyser une vulnérabilité, évaluer son niveau de criticité, comprendre pourquoi une dépendance non maintenue constitue un risque concret : ces réflexes viennent directement de ce qui a été travaillé en cours. L'architecture logicielle (R4.01) a fourni le cadre conceptuel pour comprendre l'organisation du code de production dans un environnement microservices, où la séparation des responsabilités et la gestion des dépendances ne sont plus des choix de conception mais des contraintes imposées par l'échelle du système.

Le projet personnel et professionnel (R3.14, R4.07) s'est révélé plus stratégique que prévu. Réfléchir à son positionnement, comprendre les codes du monde du travail, anticiper les transitions de carrière : ces matières ont agi comme un cadre de référence pour prendre les bonnes décisions autour de ma poursuite d'études à l'ENSIBS. Avec le recul, je regrette de ne pas avoir appliqué plus tôt leurs enseignements sur l'anticipation des cycles de recrutement.

Les traces de cette année se répartissent sur plusieurs niveaux. Les tableaux de bord bimensuels et la SAE 4.2 constituent les livrables formels accessibles à l'IUT. AC26.04 (Rendre compte de son activité professionnelle) et AC25.04 (Définir et mettre en oeuvre une démarche de suivi de projet) : la régularité de ces documents sur toute l'année, maintenue y compris lors des transitions entre périodes école et entreprise, en fait une trace directe de ces apprentissages. La soutenance à venir sera l'occasion de défendre l'ensemble formellement.

Les tickets traités dans les outils internes, Jira pour le suivi et GitLab pour le code et les pipelines CI/CD, constituent les traces techniques les plus directes. Ces outils ne sont pas accessibles à l'IUT depuis l'extérieur, ce qui est normal dans un contexte bancaire, mais les traces existent et sont vérifiables par mon maître d'alternance. AC21.01 et AC21.03 (Réaliser, implémenter les spécifications et adopter de bonnes pratiques de conception) : montées de version, évolutions d'endpoints, développement de la librairie de logging et Spring Batch de purge ont tous été implémentés en respectant les conventions de l'équipe et l'architecture microservices existante. AC21.04 (Vérifier et valider la qualité par les tests) : chaque développement passe par des tests Postman locaux, une validation fonctionnelle par la business analyste et les quality gates automatisés de la CI/CD avant tout déploiement.

AC23.02 (Utiliser des serveurs et des services réseaux virtualisés) : le déploiement régulier sur plusieurs environnements, développement, test, homologation, production, via des pipelines GitLab CI/CD est une trace directe. AC23.03 et AC22.03 (Sécuriser les services et comprendre les enjeux de sécurisation) : la remédiation de CVE et le renouvellement de certificats de chiffrement sont des missions concrètes de sécurisation des services en production. AC22.04 (Évaluer l'impact des solutions) : analyser une CVE, évaluer son niveau de criticité et ses impacts sur les dépendances avant d'intervenir est précisément l'exercice que cet apprentissage vise. AC24.01 et AC24.02 (Gérer les données et assurer leur sécurité) : le Spring Batch de purge touche directement à la gestion des données en base, et le renouvellement des certificats garantit l'intégrité et la confidentialité des échanges. AC23.01 et AC24.04 (Applications communicantes et données hétérogènes) : développer des API REST interfacées avec des systèmes legacy COBOL via mainframe illustre ces deux apprentissages simultanément.

AC25.01, AC25.02 et AC25.03 (Conduire, identifier les processus, formaliser les besoins et les critères de faisabilité) : comprendre la séparation build/run et les procédures RFC de CA-TS, rédiger des RFC pour formaliser des demandes de changement, et mener des analyses d'impact avant chaque ticket sont des traces directes. AC26.01 et AC26.02 (Comprendre la structure d'une organisation et s'y intégrer) : progresser de l'onboarding à la prise d'initiatives autonomes au sein d'une Squad agile avec des rôles définis illustre ces apprentissages. AC26.03 (Mobiliser les compétences interpersonnelles) : pair programming, coordination avec les architectes et les DBA, représentation d'une collègue absente dans ses réunions techniques.

La trace la plus publique reste l'application de paiement mobile du Crédit Agricole. Certaines des fonctionnalités sur lesquelles j'ai travaillé sont passées en production et sont aujourd'hui utilisées par des milliers de clients. Fin mai 2026, j'ai testé un parcours d'enrôlement directement sur mon compte personnel pour mieux en comprendre le fonctionnement de bout en bout. Voir le travail de l'équipe dans une application publique, c'est quelque chose qu'aucun rendu universitaire ne reproduit.

Honnêtement, peu de choses m'ont manqué sur le plan des connaissances acquises à l'IUT. Les architectures REST et la conception d'API avaient été abordées en cours et mises en pratique dans le POC de la SAE 3.B.02. GitLab et les pipelines CI/CD avaient également été vus en SAE. Les bases étaient là. Ce qui manquait, c'était simplement l'expérience professionnelle : savoir lire un projet de grande échelle existant, s'intégrer dans une équipe avec ses conventions et ses processus, prendre des décisions sous contrainte réelle. Ce n'est pas quelque chose qu'un cours peut donner. Il faut bien commencer quelque part.

La principale erreur de cette année ne concerne pas une ligne de code. J'ai fait confiance, à tort, à l'idée que mon entreprise m'aiderait à trouver une alternance pour la suite de mon parcours à l'ENSIBS. Ce n'est pas que la démarche ait manqué de bonne volonté, mais les postes et les budgets sont arbitrés en fin d'année précédente, bien avant que les besoins individuels ne soient discutés. Quand j'ai commencé à chercher activement, au printemps 2026, les entreprises qui recrutaient pour l'automne avaient déjà leur plan. J'avais perdu l'avance que j'aurais pu avoir en commençant cette recherche dès l'automne 2025.

C'est une erreur que je comprends mieux maintenant : j'avais encore un rapport scolaire au temps. À l'école, on a généralement quelques mois pour préparer une candidature, et les délais sont fixés par l'institution. En entreprise, le recrutement obéit à des cycles économiques qui n'attendent pas. Les budgets d'embauche sont votés en novembre pour l'année suivante. Les postes sont souvent pourvus en interne avant d'être publiés. Anticiper presque un an à l'avance n'est pas de la précipitation, c'est la norme. Je pense appliquer cette leçon dès la fin de mon contrat ENSIBS, en préparant mon entrée dans le marché du travail bien avant la date officielle de fin de formation.

J'aurais aussi pu contribuer à la documentation interne plus tôt dans l'année. Lors de mes premières semaines, j'avais encore un regard neuf sur l'environnement, et c'est précisément à ce moment-là qu'on voit les angles morts que les membres plus anciens ne remarquent plus. J'ai laissé passer cette fenêtre. C'est un nouveau salarié arrivé en fin d'alternance qui, fort de son expérience précédente, a demandé la documentation et fait remarquer qu'on ne pouvait rien lui fournir de solide. Avec plus d'expérience, c'est quelque chose que j'aurais initié dès le départ.