Du développeur au paiement

La chaîne des jalons

Chaque jalon renvoie à sa fiche de parcours : problème traité, promesse, prérequis, jalons mensuels et pile technique.

Aboutissement : Product Manager FinTech

Sommaire de la monographie

• —Résumé exécutif
• 01Le cursus en un coup d'œil
• 02Pourquoi cette voie — le contexte UEMOA
• 03Jalon 1 · Développeur d'API (22)
• 04La passerelle F2 → F5 — la reconversion vers la fintech
• 05Jalon 2 · Ingénieur Paiements (77)
• 06Jalon 3 · Spécialiste Mobile Money (76)
• 07Jalon 4 · Product Manager FinTech (86)
• 08Plan de mise en œuvre sur 30 mois
• 09Étude de cas — la trajectoire de Khadija
• 10Activer ce cursus — lecture RH & DSI
• 11Conclusion
• AAnnexe A — récapitulatif des quatre jalons
• BAnnexe B — compétences & certifications par jalon
• CAnnexe C — glossaire & repères
• DAnnexe D — variantes, bifurcations & cursus voisins
• EAnnexe E — indicateurs de progression par jalon
• FAnnexe F — ressources de montée en compétences

Résumé exécutif

Quatre jalons prouvés, une passerelle précoce : comment un développeur se reconvertit dans la fintech et atteint, en quelques années, la responsabilité produit.

Le cursus « Du développeur au paiement » conduit un développeur d'API jusqu'au poste de Product Manager FinTech. Sa particularité : la passerelle survient tôt et change la nature du parcours. Dès le deuxième jalon, le développeur franchit de la Famille 2 (Génie Logiciel) à la Famille 5 (FinTech & Paiement) — une reconversion latérale entre deux familles techniques, et non une promotion vers le management. Le reste du cursus se déroule dans la fintech : Ingénieur Paiements, Spécialiste Mobile Money, puis Product Manager.

Son enjeu se concentre sur ce franchissement précoce : la reconversion d'un métier technique vers un autre. Le développeur n'abandonne pas ce qu'il sait — il le transpose. La compétence-pont est le génie logiciel lui-même : conception d'API, qualité, pensée système. Ce qui change, c'est le domaine : l'argent réel, la conformité, les réalités du mobile money. C'est sur cette transposition que cette monographie insiste le plus.

Pour les organisations de la zone UEMOA, où la fintech recrute massivement des profils techniques, ce cursus est un instrument de reconversion et d'attractivité : transformer des développeurs en spécialistes du paiement et en product managers fintech, plutôt que de chercher sur un marché tendu des profils déjà rares. Ce document en détaille chaque jalon, le plan de mise en œuvre sur trente mois, une étude de cas et la lecture RH & DSI pour l'activer.

01

Le cursus en un coup d'œil

Du développement d'API à la responsabilité produit en fintech : quatre jalons, une passerelle précoce, la voie qui reconvertit un développeur vers le paiement.

Le cursus « Du développeur au paiement » occupe une place singulière dans la collection. Il part d'un poste de Développeur d'API et conduit jusqu'au poste de Product Manager FinTech. Sa particularité : la passerelle survient tôt. Dès le deuxième jalon, le développeur franchit de la Famille 2 (Génie Logiciel) à la Famille 5 (FinTech & Paiement). Ce n'est pas une promotion vers le management, mais une reconversion latérale entre deux familles techniques — un changement de domaine, pas de posture.

Le reste du cursus se déroule dans la fintech : Ingénieur Paiements, Spécialiste Mobile Money, puis Product Manager. L'aboutissement n'est donc pas un poste de direction, mais un rôle produit — celui qui synthétise la profondeur technique du développeur, la maîtrise du paiement et le sens du produit. C'est un cursus de reconversion, là où d'autres mènent au management ou à l'expertise.

Les quatre jalons

Jalon	Rôle (n°)	Famille	Niveau	Durée
1	Développeur d'API (22)	F2 · Génie Logiciel	Développer	0 – 8 mois
2	Ingénieur Paiements (77)	F5 · FinTech	Intégrer	8 – 16 mois
3	Spécialiste Mobile Money (76)	F5 · FinTech	Distribuer	16 – 24 mois
4	Product Manager FinTech (86)	F5 · FinTech	Produire	24 mois +

Profil d'entrée, profil de sortie

À l'entrée, un développeur qui conçoit des API. À la sortie, un Product Manager FinTech qui porte un produit de paiement — sa valeur, son adoption, sa trajectoire. Entre les deux, un changement de famille précoce puis une montée continue — du développer à l'intégrer, puis au distribuer, puis au produire.

02

Pourquoi cette voie — le contexte UEMOA

La fintech de la zone recrute massivement des profils techniques. Reconvertir des développeurs vers le paiement est souvent plus rapide et plus sûr que de chercher des spécialistes déjà rares.

Dans la zone UEMOA, la fintech connaît une croissance rapide — et un déficit chronique de talents. Les spécialistes du paiement, du mobile money et du produit fintech sont rares et chers. Or il existe un vivier sous-exploité : les développeurs. Beaucoup maîtrisent déjà l'essentiel — conception d'API, rigueur logicielle, pensée système — et n'attendent qu'une voie pour basculer vers un domaine porteur. Ce cursus trace cette voie.

Ce cursus répond à trois besoins structurels du marché régional. D'abord la reconversion de talents techniques : transformer des développeurs en spécialistes du paiement, plutôt que de chercher l'introuvable. Ensuite la montée en valeur métier : faire passer un profil du « comment » technique au « pourquoi » produit. Enfin l'attractivité : offrir aux développeurs une perspective d'évolution vers un secteur recherché, ce qui les fidélise.

Trois moteurs de la demande

Moteur	Ce qu'il impose	Rôle du cursus
Croissance de la fintech	Beaucoup de profils paiement et produit, vite.	Reconvertit des développeurs vers la fintech.
Pénurie de spécialistes	Trouver autrement que sur un marché tendu.	Forme en interne, à partir d'un vivier de développeurs.
Besoin de profils hybrides	Des PME qui comprennent la technique ET le produit.	Mène le développeur jusqu'à la responsabilité produit.

Pour une fintech ou une DSI de la zone, ce cursus est un instrument de reconversion et d'attractivité. Le profil qui en résulte est rare et précieux : un Product Manager qui comprend le code parce qu'il l'a écrit, le paiement parce qu'il l'a intégré, et le mobile money parce qu'il l'a fait passer à l'échelle. Cette profondeur technique au service du produit est un avantage décisif.

À qui ce cursus profite dans la zone

Employeur	Poste-cible	Pourquoi ce cursus
FinTech / agrégateur de paiement	Product Manager, ingénieur paiements	Reconvertir des développeurs vers le produit fintech.
Opérateur mobile money	Spécialiste mobile money, PM	Profils techniques qui comprennent l'usage de masse.
Banque / établissement de paiement	Ingénieur paiements, PM	Moderniser les paiements avec des profils internes.
Éditeur de logiciels / ESN	PM fintech, ingénieur paiements	Faire évoluer des développeurs vers un domaine porteur.

03

Jalon 1 · Développeur d'API (22)

• FamilleF2 · Génie Logiciel
• MouvementDépart
• NiveauDévelopper
• Durée0 – 8 mois

Le point d'entrée du cursus : maîtriser la conception d'API et la rigueur logicielle — le socle transférable sur lequel toute la reconversion s'appuiera.

Le rôle

Le Développeur d'API conçoit et construit des interfaces logicielles : conception d'API claires et versionnées, contrats d'interface, qualité du code, tests, gestion des erreurs, documentation, performance. Il est le bâtisseur des briques que d'autres consomment. C'est un rôle de « développer » : il produit du logiciel solide, lisible et maintenable. Dans ce cursus, il représente le point de départ — le métier d'origine, avant la reconversion.

Ce jalon n'est pas propre à la fintech : c'est un poste de génie logiciel classique. Mais c'est précisément ce qui en fait la force pour ce cursus. Les compétences qui s'y acquièrent — conception d'API, qualité, pensée système, gestion des erreurs — sont exactement celles qui se transposeront au paiement. Un développeur qui conçoit des API robustes et bien documentées possède déjà l'essentiel de ce qu'exige l'intégration de moyens de paiement.

Missions principales

Mission	En quoi elle consiste
Concevoir des API	Interfaces claires, versionnées, avec des contrats explicites.
Garantir la qualité	Code lisible et maintenable, tests automatisés.
Gérer les erreurs	Cas limites, robustesse, messages d'erreur exploitables.
Documenter	Rendre l'API compréhensible et utilisable par d'autres.
Optimiser	Performance et fiabilité sous charge.

Compétences à acquérir

• Conception d'API : ressources, contrats, versionnement, idempotence.
• Qualité du code : lisibilité, maintenabilité, tests automatisés.
• Gestion des erreurs et des cas limites : robustesse.
• Pensée système : comprendre comment les briques s'assemblent.
• Un langage de programmation et de bonnes pratiques d'ingénierie.
• Documentation : rendre son travail utilisable par d'autres.

Une semaine-type

Activité	Part du temps
Conception et développement d'API	≈ 45 %
Tests, qualité, gestion des erreurs	≈ 25 %
Documentation et contrats d'interface	≈ 15 %
Revue, collaboration, optimisation	≈ 15 %

Le mouvement

C'est le départ du cursus — et le métier que le professionnel va transposer, non abandonner. Le socle qu'il capitalise ici — conception d'API, qualité, pensée système — est précisément la compétence-pont qui rendra possible la passerelle vers la fintech. La qualité de ce socle conditionne la reconversion : un développeur rigoureux et soucieux des contrats d'interface deviendra un excellent ingénieur paiements ; un développeur négligent peinera.

Pièges à éviter

• Négliger les contrats d'interface : livrer des API fragiles, difficiles à intégrer.
• Coder sans tester : prendre des habitudes incompatibles avec la rigueur du paiement.
• Rester indifférent au métier : coder sans jamais se demander à quoi cela sert.

04

La passerelle F2 → F5 — la reconversion vers la fintech

Le moment où le développeur devient un professionnel de la fintech. Une passerelle d'un genre nouveau : latérale, précoce, entre deux familles techniques.

Dans la plupart des cursus de la collection, la passerelle est un franchissement vers le management (la Famille 6), placé tard, qui couronne une longue expertise. Celle-ci est différente, à trois titres. Elle est latérale : elle relie deux familles techniques (Génie Logiciel et FinTech), sans changer de posture — on reste un technicien. Elle est précoce : elle survient dès le deuxième jalon, et non au sommet. Et elle est une reconversion : un changement de domaine, pas une promotion. C'est le sujet même du cursus.

La compétence-pont

Une passerelle ne se franchit jamais à vide : elle s'appuie sur une compétence commune aux deux familles. Ici, cette compétence-pont est le génie logiciel lui-même : la conception d'API, la qualité du code, la gestion des erreurs et la pensée système. Or l'intégration de paiements est, techniquement, un travail d'API et de robustesse. Le développeur qui sait concevoir des contrats d'interface clairs, gérer l'idempotence et les cas d'erreur possède déjà l'essentiel de ce qu'exige l'ingénierie des paiements. Il ne repart pas de zéro : il transpose.

Ce qui se transfère, ce qui s'apprend

Dimension	Ce que le développeur apporte	Ce qu'il doit apprendre
Le savoir-faire	Conception d'API, qualité, robustesse	Réconciliation, idempotence financière
Le domaine	Logique applicative	Le paiement : argent réel, flux, comptabilité
Les contraintes	Performance, maintenabilité	Conformité, sécurité (PCI), réglementation
Le terrain	Le logiciel en général	Le mobile money, les agents, l'usage de masse

Ce qui se transfère est l'essentiel du métier technique ; ce qui s'apprend est le domaine. Le développeur ne change pas de nature — il reste un ingénieur — mais il découvre un univers où chaque ligne de code manipule de l'argent réel, où une erreur se compte en francs CFA, où la conformité n'est pas optionnelle. C'est un changement de domaine, exigeant mais accessible, qui s'opère en quelques mois pour qui a un bon socle.

Conditions de réussite

• Avoir un socle logiciel solide : la passerelle s'appuie dessus, elle ne le remplace pas.
• Accepter la rigueur du paiement : l'argent réel ne tolère ni approximation ni écart.
• S'immerger dans le domaine : apprendre le paiement, le mobile money, la conformité.
• Garder l'humilité du débutant dans un nouveau domaine, tout en valorisant son socle.

Pourquoi une passerelle précoce ?

Contrairement aux franchissements vers le management, cette reconversion n'exige pas une longue expertise préalable. Un bon socle de développeur suffit. La passerelle survient donc tôt, dès le deuxième jalon, et l'essentiel du cursus — l'apprentissage du paiement, du mobile money et du produit — se déroule dans la nouvelle famille. C'est une logique d'immersion : on bascule vite, puis on approfondit longuement.

05

Jalon 2 · Ingénieur Paiements (77)

• FamilleF5 · FinTech & Paiement
• MouvementPasserelle franchie (F2 → F5)
• NiveauIntégrer
• Durée8 – 16 mois

Le premier jalon dans la fintech : transposer ses compétences logicielles à l'intégration des paiements — où chaque transaction manipule de l'argent réel.

Le rôle

L'Ingénieur Paiements intègre et fiabilise les moyens de paiement : connexion aux rails (cartes, virements, mobile money), API de paiement, traitement des transactions, réconciliation, gestion des échecs, sécurité (chiffrement, conformité PCI). C'est le premier poste du développeur dans la fintech — et celui où sa compétence-pont s'exprime pleinement : intégrer un paiement, c'est avant tout un travail d'API et de robustesse. C'est un rôle d'« intégrer », désormais appliqué à l'argent réel.

Ce jalon est le premier test de la reconversion. Le développeur retrouve un terrain familier — des API, des contrats, de la gestion d'erreurs — mais avec une exigence nouvelle : la réconciliation au centime. Dans le paiement, une transaction perdue ou dupliquée n'est pas un bug à corriger un jour : c'est de l'argent réel, immédiatement. Le développeur apprend ici que sa rigueur logicielle, déjà bonne, doit devenir absolue.

Missions principales

Mission	En quoi elle consiste
Intégrer les rails	Connecter cartes, virements, mobile money via leurs API.
Traiter les transactions	Autorisation, capture, remboursement, gestion des échecs.
Réconcilier	Rapprocher les flux, garantir l'exactitude comptable au centime.
Sécuriser	Chiffrement, conformité PCI, protection des données de paiement.
Fiabiliser	Idempotence, renvois, robustesse face aux pannes des partenaires.

Compétences à acquérir

• Intégration d'API de paiement : rails cartes, virements, mobile money.
• Cycle de vie d'une transaction et idempotence financière.
• Réconciliation : l'exactitude comptable, nouveauté du domaine.
• Sécurité du paiement : conformité PCI, tokenisation.
• La culture du paiement : l'argent réel, le risque, la conformité.
• Transposition de son socle logiciel à un domaine exigeant.

Une semaine-type

Activité	Part du temps
Intégration et fiabilisation des rails de paiement	≈ 40 %
Traitement des transactions, gestion des échecs	≈ 25 %
Réconciliation et exactitude comptable	≈ 20 %
Sécurité, conformité, immersion dans le domaine	≈ 15 %

Le mouvement

Premier jalon après la passerelle F2 → F5 (77, dans la nouvelle famille). Le développeur confirme sa reconversion en transposant son savoir-faire au paiement. Ce jalon est décisif : c'est ici qu'il valide que sa compétence-pont — le génie logiciel — tient la route dans le nouveau domaine. La maîtrise acquise prépare le jalon suivant, où il passera de l'intégration unitaire au service de masse.

Pièges à éviter

• Traiter le paiement comme une API ordinaire : ignorer la réconciliation et l'idempotence.
• Sous-estimer la conformité : manipuler de l'argent réel sans la rigueur réglementaire.
• Rester en surface du domaine : intégrer sans comprendre les flux financiers.

06

Jalon 3 · Spécialiste Mobile Money (76)

• FamilleF5 · FinTech & Paiement
• MouvementTrajectoire interne (F5 → F5)
• NiveauDistribuer
• Durée16 – 24 mois

Du paiement intégré au paiement de masse : faire passer le service à l'échelle de millions d'utilisateurs, via les agents, l'USSD et l'interopérabilité.

Le rôle

Le Spécialiste Mobile Money maîtrise le paiement à l'échelle de la zone : plateformes de mobile money, canaux (USSD, applications, agents), réseau d'agents (cash-in / cash-out, liquidité), interopérabilité entre opérateurs, conformité (KYC, lutte anti-blanchiment), gestion du volume et de la fraude. Là où l'ingénieur paiements intègre une brique, lui orchestre une distribution de masse. C'est un rôle de « distribuer » : il fait du paiement un service accessible à des millions de personnes.

Ce jalon ancre la reconversion dans la réalité de la zone UEMOA, où le mobile money est l'infrastructure financière dominante. Le développeur reconverti y découvre des réalités qu'aucun logiciel classique ne lui avait apprises : la gestion de la liquidité des agents, l'USSD comme canal universel, et l'interopérabilité entre opérateurs. C'est ici que le profil cesse d'être un développeur qui fait du paiement pour devenir un véritable spécialiste de la fintech régionale.

Missions principales

Mission	En quoi elle consiste
Opérer le mobile money	Plateformes, canaux (USSD, app), parcours de paiement.
Animer le réseau d'agents	Cash-in / cash-out, liquidité, qualité de service terrain.
Assurer l'interopérabilité	Relier les opérateurs pour des transferts fluides.
Gérer le volume & la fraude	Tenir la charge, détecter et limiter la fraude.
Garantir la conformité	KYC, lutte anti-blanchiment, protection du client.

Compétences à acquérir

• Plateformes mobile money : architecture, canaux, parcours utilisateur.
• USSD et canaux universels : toucher tout téléphone, même sans smartphone.
• Réseau d'agents : liquidité, cash-in/out, qualité terrain.
• Interopérabilité : standards et intégration entre opérateurs.
• Conformité : KYC, lutte anti-blanchiment.
• Gestion du volume et détection de la fraude à grande échelle.

Une semaine-type

Activité	Part du temps
Opération et amélioration du service mobile money	≈ 35 %
Interopérabilité et intégration des acteurs	≈ 25 %
Réseau d'agents, liquidité, qualité terrain	≈ 20 %
Conformité (KYC/LAB) et lutte anti-fraude	≈ 20 %

Le mouvement

Trajectoire interne F5 → F5 (77 → 76). Du paiement intégré au paiement distribué à l'échelle. L'ingénieur paiements fait désormais grandir un service touchant des millions de personnes. Ce jalon est décisif pour la suite : c'est en comprenant l'usage de masse, les agents et l'interopérabilité que le profil acquiert la connaissance du terrain qui fera un bon Product Manager. On ne produit bien un produit que pour des usages que l'on connaît intimement.

Pièges à éviter

• Ignorer l'USSD : concevoir pour le smartphone et exclure la majorité des usagers.
• Négliger la liquidité des agents : un agent à sec, c'est un client bloqué.
• Rester ingénieur dans la tête : ne pas s'ouvrir à la dimension usage et terrain.

07

Jalon 4 · Product Manager FinTech (86)

• FamilleF5 · FinTech & Paiement
• MouvementTrajectoire interne (F5 → F5) · Aboutissement
• NiveauProduire
• Durée24 mois +

L'aboutissement du cursus : porter un produit de paiement de bout en bout — sa valeur, son adoption, sa trajectoire — avec la profondeur technique d'un ancien développeur.

Le rôle

Le Product Manager FinTech porte un produit de paiement de bout en bout : compréhension des besoins (discovery), feuille de route, priorisation, métriques d'adoption et de rétention, mise sur le marché, dialogue avec la technique, le commerce et la conformité. Là où le spécialiste mobile money fait fonctionner le service, lui décide quoi construire et pourquoi. C'est un rôle de « produire » — l'aboutissement de la reconversion : le développeur d'hier est devenu un responsable produit qui pense valeur et usage.

Ce jalon couronne le cursus en faisant la synthèse de tout le parcours. Le Product Manager issu de cette voie est rare : il possède la profondeur technique d'un ancien développeur, la maîtrise du paiement d'un ingénieur fintech, et la connaissance du terrain d'un spécialiste mobile money. Quand il estime une faisabilité, il ne dépend pas entièrement d'autrui : il sait. Quand il arbitre, il comprend les implications techniques. Cette crédibilité fait de lui un PM redoutablement efficace dans la fintech.

Notons-le : l'aboutissement de ce cursus n'est pas un poste de management. Le Product Manager n'a généralement pas d'autorité hiérarchique : il influence, il aligne, il décide de la valeur — mais il ne dirige pas une équipe au sens RH. C'est un rôle de leadership produit, distinct du management. Pour qui souhaite ensuite diriger, la voie reste ouverte (voir la conclusion) ; mais le cursus, lui, s'accomplit dans le produit.

Missions principales

Mission	En quoi elle consiste
Comprendre les besoins	Discovery : usages, frictions, opportunités du marché.
Prioriser la feuille de route	Arbitrer entre demandes, dire non, séquencer la valeur.
Mesurer l'adoption	Métriques d'usage, de rétention, de valeur créée.
Estimer la faisabilité	Évaluer le coût et le risque technique — avec crédibilité.
Coordonner sans autorité	Aligner technique, conformité et métier autour du produit.

Compétences à acquérir

• Product discovery : comprendre les usages et les frictions réelles.
• Priorisation : arbitrer, séquencer, savoir dire non.
• Métriques produit : adoption, rétention, valeur — pas la vanité.
• Go-to-market : lancer et faire adopter un produit de paiement.
• Coordination transverse et influence sans lien hiérarchique.
• Mise au service du produit de tout le socle technique acquis.

Une semaine-type

Activité	Part du temps
Discovery, dialogue avec les usages et les métiers	≈ 30 %
Feuille de route, priorisation, arbitrages	≈ 25 %
Mesure de l'adoption et de la valeur	≈ 20 %
Go-to-market et coordination transverse	≈ 25 %

Le mouvement

Trajectoire interne F5 → F5 (76 → 86), et aboutissement du cursus. La reconversion est complète : le développeur est devenu un responsable produit fintech, riche d'un socle technique que peu de PM possèdent. Ce sommet n'est pas un poste de management mais un rôle produit — une destination en soi, qui valorise pleinement le chemin parcouru. Pour qui le souhaite, il peut ensuite ouvrir vers la direction produit ou la direction de programme (voir la conclusion).

Pièges à éviter

• Rester développeur dans sa tête : vouloir coder au lieu de porter le produit.
• Sur-estimer sa maîtrise technique : croire tout savoir et ne plus écouter la technique.
• Construire sans discovery : livrer ce que personne n'adopte, malgré le socle technique.

08

Plan de mise en œuvre sur 30 mois

Un jalon à la fois, une preuve à chaque étape : la cadence qui sécurise la reconversion du développeur au responsable produit fintech.

Le cursus se déploie sur une trentaine de mois, du développement d'API à la responsabilité produit. La règle est constante : chaque jalon mobilise plusieurs mois, le temps de produire une preuve déployable avant d'ouvrir le suivant. La particularité tient à la passerelle : elle survient tôt, dès le passage du jalon 1 au jalon 2, et l'essentiel du cursus se déroule ensuite dans la fintech.

Phase	Mois	Objectif	Preuve attendue
Jalon 1	M1 – M8	Maîtrise du génie logiciel (API)	API solide, testée, documentée, utilisée
Passerelle	M6 – M9	Reconversion vers la fintech	Immersion paiement, transposition du socle
Jalon 2	M9 – M16	Intégration des paiements	Moyen de paiement en production, réconcilié
Jalon 3	M17 – M24	Mobile money à l'échelle	Service interopérable, conforme, tenant le volume
Jalon 4	M25 – M30+	Product management d'un produit de paiement	Produit adopté + métriques de valeur

Le détail par grandes étapes

Période	Focus	Livrable de la période
M1 – M8	Conception d'API, qualité, tests, documentation	API solide en production
M6 – M9	Immersion fintech : paiement, conformité, domaine	Bascule réussie vers la nouvelle famille
M9 – M16	Intégration, transaction, réconciliation, sécurité	Paiement fiable en production
M17 – M24	Mobile money, agents, USSD, interopérabilité	Service mobile money à l'échelle
M25 – M30+	Discovery, feuille de route, métriques, go-to-market	Produit de paiement adopté

09

Étude de cas — la trajectoire de Khadija

Comment WaariPay reconvertit en interne, en trente mois, une développeuse en Product Manager de son produit de paiement phare — sans recrutement externe.

Le point de départ

Khadija est développeuse d'API chez WaariPay : quatre ans d'expérience, des API propres et bien documentées, et une curiosité pour le métier au-delà du code. Elle aime comprendre à quoi sert ce qu'elle construit. La fintech, qui peine à recruter des spécialistes du paiement et veut faire émerger des profils produit, identifie en elle un potentiel et lui propose le cursus « Du développeur au paiement ».

La trajectoire, par grandes étapes

Étape	Jalon	Preuve produite
Phase 1	Développeuse d'API (22)	API de services internes, solides et documentées, adoptées par plusieurs équipes.
Passerelle	Reconversion F2 → F5	Immersion réussie dans le domaine du paiement, transposition du socle logiciel.
Phase 2	Ingénieure Paiements (77)	Intégration d'un moyen de paiement en production, réconciliée au centime.
Phase 3	Spécialiste Mobile Money (76)	Service de transfert interopérable, à l'échelle, conforme et résistant à la fraude.
Phase 4	Product Manager FinTech (86)	Lancement d'un produit de paiement marchand, adopté et mesuré.

Le bilan

En une trentaine de mois, Khadija est passée d'un rôle de développeuse à la responsabilité produit d'un service de paiement phare. Chaque étape s'est validée par une preuve déployable, ce qui a permis à la fintech de sécuriser sa reconversion sans pari. WaariPay a transformé une développeuse de talent en un profil produit rare — sans dépendre d'un marché de spécialistes tendu.

Les trois décisions-clés de la direction

La réussite de Khadija ne tient pas au hasard mais à trois décisions de la direction. D'abord, choisir le bon profil : une développeuse rigoureuse et curieuse du métier, pas seulement la plus technique. Ensuite, accompagner la passerelle : un soin particulier à l'immersion dans le domaine du paiement, le moment le plus délicat. Enfin, exiger la preuve : aucune étape validée sans livrable déployable, ce qui a permis d'avancer sans pari.

Le calcul économique

	Recrutement externe	Reconversion interne (Khadija)
Délai	6 – 12 mois de recherche, profil produit fintech rare	Reconversion planifiée, à partir d'un vivier interne
Coût	Prime de rareté, package élevé, risque d'échec	Accompagnement (mentors, temps) bien moindre
Risque	Méconnaissance de la technique et du contexte	Profil connu, double socle technique et fintech
Fidélisation	Intégration incertaine, départ possible	Développeuse fidélisée par une perspective rare

10

Activer ce cursus — lecture RH & DSI

De l'intention au pilotage : comment une direction RH, une DSI ou une fintech met concrètement ce cursus de reconversion en mouvement.

Quatre usages pour une direction

Usage	Ce que le cursus permet
Reconversion de talents	Transformer des développeurs en profils fintech rares.
Réponse à la pénurie	Former en interne plutôt que chercher l'introuvable.
Fidélisation	Offrir aux développeurs une perspective vers un secteur porteur.
Profils hybrides	Faire émerger des PM qui comprennent vraiment la technique.

Une feuille de route en 90 jours

À J+30, repérer les développeurs à fort potentiel (ceux qui ont un bon socle et une curiosité du métier) et le poste-cible (ingénieur paiements, puis PM). À J+60, valider l'appétence des candidats pour la fintech et désigner sponsor et mentors. À J+90, lancer le jalon 1 — ou la passerelle si le socle logiciel est déjà solide — avec une preuve attendue claire et un accompagnement renforcé sur l'immersion fintech.

Facteurs de réussite & risques

Facteur de réussite	Risque symétrique à éviter
Socle logiciel solide avant la passerelle	Reconvertir un développeur au socle fragile
Accompagnement renforcé de l'immersion fintech	Sous-estimer la spécificité du domaine paiement
Preuve déployable validée à chaque jalon	Valider la progression sur la seule bonne volonté
Respect de la rigueur du paiement	Traiter l'argent réel comme un logiciel ordinaire

11

Conclusion

Une voie de reconversion vers la fintech, à condition d'en respecter la discipline : la preuve à chaque jalon, et une immersion sérieuse dans le domaine du paiement.

« Du développeur au paiement » est un cursus à part dans la collection : ni une voie vers le management, ni une pure voie d'expertise, mais une reconversion latérale d'une famille technique vers une autre. Il a pour lui la cohérence : un socle logiciel solide qui se transpose au paiement, puis une montée continue jusqu'à la responsabilité produit. Il a contre lui une exigence : la passerelle, bien que précoce et accessible, ne doit pas être prise à la légère. Traiter le paiement comme un logiciel ordinaire, c'est rater la reconversion.

Pour le professionnel, ce cursus offre une perspective précieuse : quitter un métier de développeur parfois saturé pour un secteur porteur, sans repartir de zéro — en transposant son socle. Pour l'employeur, il offre un instrument de reconversion et d'attractivité : faire émerger des spécialistes du paiement et des product managers à partir d'un vivier de développeurs, plutôt que de dépendre d'un marché tendu. Pour la zone UEMOA, il répond à un besoin structurel : alimenter la croissance de la fintech en talents, à partir des compétences techniques déjà présentes.

Trois principes à retenir

• La preuve, pas la promesse : chaque jalon se valide par un livrable déployable.
• Le socle se transpose : le génie logiciel est la compétence-pont vers la fintech.
• Le domaine se respecte : l'argent réel exige une rigueur que le logiciel n'impose pas toujours.

Pour aller plus loin

Ce cursus dialogue avec ses voisins. Le Product Manager FinTech (86) peut prolonger vers le leadership d'écosystème puis la direction de programme — précisément la suite tracée par le cursus « De la fintech à l'écosystème », dont il partage plusieurs jalons. Le présent cursus est ainsi une porte d'entrée dans la fintech ; d'autres cursus en prolongent la trajectoire vers l'écosystème, le management ou l'expertise.

A

Annexe A — récapitulatif des quatre jalons

Jalon	Rôle (n°)	Famille	Mouvement	Durée
1	Développeur d'API (22)	F2	Départ	0 – 8 mois
2	Ingénieur Paiements (77)	F5	Passerelle F2 → F5	8 – 16 mois
3	Spécialiste Mobile Money (76)	F5	Interne	16 – 24 mois
4	Product Manager FinTech (86)	F5	Interne · Aboutissement	24 mois +

• Enchaînement complet22 → 77 → 76 → 86
• · FamillesF2 → F5 → F5 → F5
• · AboutissementProduct Manager FinTech (86).

B

Annexe B — compétences & certifications par jalon

Jalon	Compétences clés	Certification / preuve cible
Développeur d'API (22)	Conception d'API, qualité, tests, pensée système	Certifs développement / API
Ingénieur Paiements (77)	Intégration, transaction, réconciliation, sécurité (PCI)	Certifs paiement / sécurité
Spécialiste Mobile Money (76)	Plateformes, USSD, agents, interopérabilité, KYC/LAB	Certifs mobile money / conformité
Product Manager (86)	Discovery, priorisation, métriques, go-to-market	Certifs product management

C

Annexe C — glossaire & repères

Terme	Définition
API	Interface logicielle permettant à des services de communiquer entre eux.
Idempotence	Propriété garantissant qu'une même opération répétée ne produit pas de doublon.
Réconciliation	Rapprochement des flux pour garantir l'exactitude comptable au centime.
Mobile money	Service financier reposant sur le téléphone, sans compte bancaire classique.
USSD	Canal fonctionnant sur tout téléphone via des codes, sans Internet ni application.
Interopérabilité	Capacité des services de différents opérateurs à échanger entre eux.
KYC / LAB	Connaissance du client / lutte anti-blanchiment : obligations de conformité.
Product discovery	Démarche d'identification des vrais besoins avant de construire.
Compétence-pont	Compétence commune à deux familles, qui rend possible le passage de l'une à l'autre.
Reconversion latérale	Changement de famille technique sans changement de posture (pas vers le management).

D

Annexe D — variantes, bifurcations & cursus voisins

« Du développeur au paiement » n'est pas l'unique destin d'un développeur. Plusieurs bifurcations s'ouvrent en chemin, et son aboutissement peut lui-même se prolonger.

Ce cursus décrit une voie de reconversion directe, mais le graphe des compétences en autorise d'autres. L'Ingénieur Paiements (77) comme le Product Manager (86) sont des rôles-charnières : depuis ces points, plusieurs trajectoires divergent. Connaître ces bifurcations aide une direction à orienter chaque talent.

Trois bifurcations fréquentes

Bifurcation	Point de départ	Vers	Cursus voisin
Vers l'écosystème	Product Manager (86)	Lead Écosystème, direction de programme	Cursus 7 · De la fintech à l'écosystème
Vers l'ingénierie fintech	Ingénieur Paiements (77)	Architecte paiement, expert technique	Voie d'expertise fintech
Retour vers le logiciel	Ingénieur Paiements (77)	Architecte logiciel (cursus 4)	F5 → F2 (si la fintech ne convient pas)

Le prolongement naturel

L'aboutissement de ce cursus — le Product Manager FinTech (86) — est précisément le troisième jalon du cursus « De la fintech à l'écosystème ». Les deux cursus se rejoignent ainsi : celui-ci est une porte d'entrée (du logiciel vers la fintech), celui-là un prolongement (de la fintech vers l'écosystème et la direction). Un même professionnel peut enchaîner les deux : reconversion d'abord, montée vers l'écosystème ensuite.

E

Annexe E — indicateurs de progression par jalon

Comment objectiver l'avancement : pour chaque jalon, un indicateur de maîtrise et sa cible, à revoir avant d'ouvrir le suivant.

Jalon	Indicateur de maîtrise	Cible de fin de jalon
1 · Développeur d'API (22)	Qualité du socle logiciel	API solide, testée, documentée, adoptée
Passerelle F2 → F5	Réussite de l'immersion	Maîtrise des fondamentaux du domaine paiement
2 · Ingénieur Paiements (77)	Transposition réussie	Intégration en production, réconciliation exacte
3 · Mobile Money (76)	Service à l'échelle	Transferts interopérables, conformes, tenant le volume
4 · Product Manager (86)	Adoption & valeur	Produit adopté, métriques de valeur au vert

F

Annexe F — ressources de montée en compétences

Pour chaque jalon, les modalités d'apprentissage les plus efficaces : la pratique d'abord, la preuve ensuite, le mentorat tout du long.

Jalon	Modalités de montée en compétences
Développeur d'API (22)	Conception d'API réelles, revues de code, ateliers qualité et tests ; mentorat d'un développeur senior.
Passerelle F2 → F5	Immersion dans le domaine du paiement : lectures, observation, accompagnement renforcé sur la rigueur financière.
Ingénieur Paiements (77)	Intégrations réelles avec réconciliation, simulations d'échec, sécurité du paiement ; mentorat d'un ingénieur paiements.
Spécialiste Mobile Money (76)	Travail sur un service à l'échelle, parcours USSD, immersion terrain agents ; mentorat d'un spécialiste mobile money.
Product Manager (86)	Discovery réelle, feuille de route, mesure d'adoption, go-to-market ; mentorat d'un Product Manager confirmé.

G	Annexe G — anti-modèles à éviter dans ce cursus

Les erreurs récurrentes qui font dérailler la reconversion — et l'antidote correspondant, à garder en tête à chaque jalon.

Anti-modèle	Pourquoi il nuit	Antidote
Le socle fragile	Reconvertir un développeur médiocre échoue : la passerelle s'appuie dessus.	Consolider le socle logiciel avant de basculer.
Le paiement-comme-logiciel	Traiter l'argent réel comme une API ordinaire mène au désastre.	Respecter la rigueur du domaine : réconciliation, conformité.
L'immersion bâclée	Survoler le domaine condamne la suite du cursus.	Accompagner sérieusement la passerelle précoce.
Le tout-smartphone	Concevoir sans USSD exclut la majorité des usagers.	Penser le canal universel et le réseau d'agents.
Le PM resté développeur	Vouloir coder au lieu de porter le produit dénature le rôle.	Assumer le passage du « comment » au « pourquoi ».
La crédibilité mal placée	Croire tout savoir techniquement et ne plus écouter l'équipe.	Mettre son socle au service du produit, avec humilité.

H	Annexe H — trois portes d'entrée dans la fintech

On peut rejoindre la fintech par plusieurs chemins. Chacun apporte une force distinctive — et un angle mort à combler. Comprendre d'où vient un profil éclaire ce qu'on peut en attendre.

La fintech n'a pas une seule porte d'entrée. Un professionnel peut y venir du génie logiciel — c'est la voie de ce cursus —, de la data ou de l'infrastructure. Aucun de ces chemins n'est meilleur dans l'absolu : chacun apporte une sensibilité propre. Mais ils ne produisent pas le même profil fintech.

Porte d'entrée	Force apportée	Angle mort à combler
Du génie logiciel (ce cursus, F2)	Conception d'API, qualité, robustesse, pensée système.	Le domaine : argent réel, mobile money, conformité.
De la data (F3)	Analytics, scoring, modèles, gouvernance des données.	L'intégration transactionnelle et le temps réel.
De l'infrastructure (F1)	Fiabilité, scalabilité, exploitation à grand volume.	Le produit, l'usage et la dimension métier.

La force du profil de ce cursus est précieuse : le développeur reconverti apporte une maîtrise technique directement utile à l'intégration des paiements, et la transpose jusqu'au produit. Pour une organisation, l'idéal est de réunir plusieurs portes d'entrée complémentaires — mais celle du génie logiciel est souvent la plus naturelle, car l'intégration des paiements est avant tout un travail d'ingénierie.

I	Annexe I — questions fréquentes

Les interrogations les plus courantes des directions et des candidats au moment d'engager ce cursus.

Pourquoi la passerelle survient-elle si tôt ?

Parce que cette passerelle est une reconversion latérale, non un franchissement vers le management. Elle n'exige pas une longue expertise préalable : un bon socle de développeur suffit. On bascule donc tôt vers la fintech, dès le deuxième jalon, puis on approfondit longuement dans le nouveau domaine. C'est une logique d'immersion précoce.

Un développeur peut-il vraiment devenir Product Manager ?

Oui, et il y excelle souvent. Le PM issu de ce cursus possède une profondeur technique que peu de product managers ont : il comprend la faisabilité, le coût et le risque parce qu'il les a vécus. À condition d'assumer le changement de posture — passer du « comment » technique au « pourquoi » produit —, c'est un profil redoutablement efficace en fintech.

Faut-il abandonner le code définitivement ?

Le code n'est pas abandonné, il est transposé puis dépassé. Aux jalons 2 et 3, le profil code encore beaucoup — intégrations, services. Au jalon 4 (produit), il code moins, mais sa compréhension du code reste un atout permanent. Le cursus ne renie pas le développeur : il l'élève vers un rôle où sa technique sert le produit.

Et si la fintech ne convient finalement pas ?

La reconversion n'est pas irréversible. Un développeur qui découvre que la fintech ne lui convient pas peut revenir au génie logiciel : son socle est intact, et il aura gagné une expérience du domaine du paiement précieuse partout. La passerelle précoce limite d'ailleurs le risque : on teste la fintech tôt, avant d'y avoir tout investi.

Combien de temps faut-il réellement ?

Une trentaine de mois pour aller du développement d'API à la responsabilité produit. Le rythme dépend du socle initial : un développeur déjà solide franchira la passerelle plus vite. Le cursus trace le chemin et ses preuves, il ne garantit pas le calendrier. Mieux vaut une immersion réussie que deux jalons survolés.

Ce cursus convient-il aux petites structures ?

Oui, et particulièrement. Dans une petite fintech, reconvertir un développeur interne vers le paiement et le produit est souvent la seule option réaliste face à la pénurie de spécialistes. La logique des jalons et des preuves reste la même ; seul le rythme s'adapte aux moyens.

Ce document constitue l'approfondissement du Cursus 8 · Du développeur au paiement, huitième des treize cursus de la collection « Les cursus intra & inter familles » de la Méthode SAKITI.