Le premier concours
Un concours d’algorithmique au collège, à Toulouse. Le premier problème que j’ai eu envie de résoudre pour lui-même, pas pour la note.
Altitude 00 — le curseurParis, France · 48.85°N
Yohan Canac
Product Manager, ingénieur d’abord
Tout a commencé par un concours d’algorithmique, au collège.
Ce site n’est pas une galerie de projets. C’est un mouvement de caméra qui recule, lentement, jusqu’à ce que l’image complète apparaisse.
Ouvert aux échanges
Le fil
J’ai appris à construire des systèmes avant d’apprendre à construire des produits.
Les deux se ressemblent plus qu’on ne le croit.Qui parle
Paris, France
YCYohan Canac
Je conçois des produits en partant de ce que la technique rend possible.
J’ai découvert l’informatique au collège, à Toulouse, dans des concours d’algorithmique. Ensuite j’ai touché à tout ce qui se démontait — le logiciel comme le matériel. J’ai choisi EPITA pour ce qu’elle avait de plus technique, et je n’ai pas été déçu.
En quatrième année, en stage comme développeur full-stack, j’ai compris que ce qui m’intéressait n’était pas de résoudre le problème, mais de choisir lequel méritait de l’être. C’est ce déplacement qui m’a mené au produit — sans jamais quitter la technique.
0années à construire
+0projets livrés
+0équipes accompagnées en 5 mois
Altitude 01 — la trajectoire
Le chemin, dans l’ordre où il s’est présenté.
Rien de tout cela n’était planifié. Chaque étape a rendu la suivante évidente.
Faites défiler horizontalementEPITA
Cinq ans d’école d’ingénieurs, choisie pour ce qu’elle avait de plus technique. Algorithmique, systèmes, réseaux — la grammaire avant les phrases.
Construire pour de vrai
Les années de projets. Du code qui sort de l’exercice et rencontre quelqu’un qui l’utilise, puis s’en plaint.
Le stage
Cinq mois comme développeur full-stack. La question la plus difficile n’était plus comment construire, mais quoi construire.
La bascule
Diplômé, puis Product Manager — d’abord en stage, aujourd’hui en CDI. Même métier, autre altitude.
Chapitre IALT.01
Découvrir
IJe savais écrire du code. Je ne savais pas encore ce que ça devenait quand trois autres personnes écrivaient dans le même dépôt.
Faire quelque chose à plusieurs
012021Archivé
Première partie
Un jeu vidéo, une équipe de quatre, et le réseau à faire tenir
Un jeu multijoueur construit à quatre, en C# sous Unity. J’étais en charge du multijoueur : la partie qu’on ne voit pas, et celle qui casse.
Le problème
Un sujet volontairement fun pour un premier projet d’équipe — sauf que le multijoueur ne pardonne rien. Deux machines, deux horloges, et un état de jeu qui doit rester le même des deux côtés.
La réponse
J’ai pris le réseau et je m’y suis tenu : synchronisation de l’état, gestion des connexions, et des parties jouables à plus de dix. Le reste de l’équipe couvrait les niveaux, le design et l’interface — et il a fallu apprendre à travailler sur un dépôt commun sans s’écraser.
Résultats
0personnes dans l’équipe
0niveaux construits
0+joueurs en simultané
Technologies
- C#
- Unity
- Git
Chapitre IIALT.02
Comprendre
IIUne application, ce n’est pas un écran. C’est un compte, une session, une API tierce, et un quota qu’on découvre un vendredi soir.
Voir ce qu’il y a derrière l’écran
022022
Respirer
Une application de méditation, sur Android et iOS
Une application mobile de méditation et de bien-être, compatible Android et iOS, adossée à des contenus YouTube et à un backend Firebase.
ArchivéLe problème
Diffuser des séances sans les héberger, gérer des comptes utilisateurs, et faire tenir tout cela sur deux systèmes qui ne s’accordent sur presque rien.
La réponse
La lecture des contenus passe par YouTube plutôt que par une infrastructure vidéo à reconstruire, et Firebase gère les accès et les données. La meilleure décision technique du projet a surtout été celle de ne pas construire.
Résultats
0systèmes visés, une seule équipe
0base de code pour les deux
0vidéo hébergée par nos soins
Technologies
- Firebase
- YouTube Data API
- Android
- iOS
Chapitre IIIALT.03
Persévérer
IIIDeux semaines pendant lesquelles la seule variable ajustable était moi. Ce que j’y ai appris n’est pas une compétence : c’est un seuil.
Échouer, réessayer, réussir
032023Archivé
La piscine
Deux semaines, cent exercices, aucune marge
Le C appris de A à Z en deux semaines, de huit heures du matin à minuit. Plus de cent exercices, et pas le droit à l’erreur.
Technologies
- C
- Git
Le problème
Apprendre un langage sans filet, dans un format calibré pour que la difficulté dépasse ce qu’on peut absorber. La question n’était pas de tout finir : elle était de ne pas s’arrêter.
La réponse
Aucune astuce. Un rythme tenu quatorze jours d’affilée, des exercices repris jusqu’à ce qu’ils passent, et l’acceptation qu’un échec le matin ne dit rien de la journée.
Résultats
0+exercices rendus
0semaines
0hheures par jour
Ce qui résiste ne se contourne pas. On y revient, jusqu’à ce que ce soit soi qui ait changé.
Entre l’effort et la maîtrise
Chapitre IVALT.04
Exécuter
IVRepartir de zéro, jusqu’à ce que la machine obéisse. Et découvrir, dans la foulée, que le plus difficile n’était déjà plus là.
Construire jusqu’au bout
042024Archivé
Rendre la main
Un shell POSIX reconstruit depuis zéro, en C
Recréer un terminal POSIX complet : de la frappe au clavier jusqu’à l’exécution de n’importe quelle commande. En C, à quatre, en un mois, sans rien réutiliser.
Le problème
Un shell paraît simple tant qu’on ne l’écrit pas. Derrière l’invite il y a un lexer, une grammaire, des redirections, des processus, des signaux — et une norme qui décrit tout cela au caractère près.
La réponse
Le projet a été découpé comme un compilateur : lecture, analyse lexicale, arbre syntaxique, exécution. Chaque couche testée seule avant d’être branchée. Le véritable apprentissage a été le workflow — branches, revues, intégration continue.
Résultats
0développeurs sur le projet
0nuits très longues
0%du langage recodé, sans exception
Technologies
- C
- POSIX
- Make
- Git
052024
Sept millions
La refonte d’un parcours critique, à l’échelle d’un groupe entier
Cinq mois de stage comme développeur full-stack. J’y ai mené la refonte d’un menu utilisé pour créer les comptes de sept millions d’employés — un point de passage critique, sans droit à l’erreur.
En ligneLe problème
Un parcours ancien, utilisé quotidiennement par des équipes internes, et dont dépendait l’accès de sept millions de personnes. Impossible de le reprendre en repartant de zéro : il fallait le refaire sans jamais l’interrompre.
La réponse
Une refonte progressive côté Angular, écran par écran : conserver strictement le comportement existant là où il faisait loi, le corriger là où il coûtait du temps aux équipes. Le travail le plus utile n’a pas été le code — il a été de comprendre qui s’en servait, et pourquoi.
Résultats
0millions de comptes concernés
0mois de mission
Technologies
- Angular
- TypeScript
- SCSS
J’ai passé cinq mois à répondre à la question. Puis j’ai regardé la personne assise à côté de moi, dont le métier était de la poser.
Le moment où la question a changé
Chapitre VALT.05
Concevoir
VUn vrai client, de vrais utilisateurs. La première fois où la bonne réponse technique dépendait d’une question qui ne l’était pas.
Décider avant d’écrire
062025En ligne
Le premier client
Tech lead sur une plateforme de diffusion en direct
Un projet d’école, mais un vrai client et de vrais utilisateurs derrière : une solution de streaming en direct et d’hébergement vidéo. Mon rôle : concevoir les solutions techniques avant de les exécuter.
Technologies
- React
- Node.js
Le problème
Le client décrivait un besoin, pas une architecture. Diffuser en direct et héberger de la vidéo recouvre une dizaine de décisions techniques dont aucune ne se déduit du cahier des charges.
La réponse
Traduire la demande en options, estimer ce que chacune coûtait, défendre celle qu’on retenait — et seulement ensuite écrire le code. C’est le premier projet où j’ai passé plus de temps à décider qu’à implémenter.
Résultats
0vrai client, pas un sujet d’école
Concevoir, c’est répondre. Décider, c’est accepter qu’on ne répondra pas à tout.
Entre la conception et la décision
Chapitre VIALT.06
Décider
VICinq personnes, un périmètre trop grand, une date. Le travail n’est plus de tout faire : il est de choisir ce qui compte.
Choisir ce qu’on ne fera pas
072026En ligne
Deux clouds
Chef de projet sur la construction d’un cloud hybride
Une équipe de cinq, un cloud hybride mêlant privé et public, capable de déployer des applications à la demande sur des environnements isolés. J’ai dirigé le projet et construit la partie privée.
Le problème
Déployer à la demande, sur des environnements isolés, en combinant une infrastructure qu’on possède et une qu’on loue. Deux modèles qui n’ont ni les mêmes coûts, ni les mêmes limites, ni la même façon de tomber en panne.
La réponse
Un schéma d’architecture posé avant tout développement, un découpage du travail entre cinq personnes, et un dialogue tenu avec le client d’un bout à l’autre. Sur la partie privée, j’ai construit ce que j’avais spécifié — la meilleure façon de vérifier une spécification.
Résultats
0personnes pilotées
0infrastructures à faire coexister
Technologies
- OpenStack
- AWS
L’atelier
Les outils, et ce qu’ils m’ont appris.
Aucun de ces noms n’a d’intérêt en soi. Ce qui compte, c’est le type de problème qu’ils m’ont forcé à comprendre.
Langages05
- C
- C#
- TypeScript
- JavaScript
- SQL
La grammaire. On en change souvent, la logique reste.
Interface04
- React
- Angular
- SCSS
- Unity
Là où le produit devient tangible pour quelqu’un.
Services03
- Node.js
- Firebase
- REST
Ce qui doit tenir quand personne ne regarde.
Infrastructure05
- OpenStack
- AWS
- Linux
- Git
- CI/CD
La discipline qui m’a appris à penser en systèmes.
Produit05
- Jira
- Confluence
- Claude
- Notion
- Miro
Les outils qui remplacent l’intuition par des faits.
Design04
- Figma
- Design systems
- Prototyping
- WCAG
Moins un métier qu’une exigence sur le détail.
Ce en quoi je crois
La technique n’est pas ce qui sépare un ingénieur d’un product manager. C’est ce qui leur permet de se parler.
Je n’ai jamais considéré le code comme une fin. C’était une manière d’avoir une prise sur le réel — de transformer une idée en quelque chose qu’on peut critiquer, mesurer, améliorer. Le produit fait exactement la même chose, à une autre échelle.
— Yohan Canac
Ce que j’ai appris
Cinq choses que je n’aurais pas pu apprendre autrement.
La basculeAltitude ∞
Je ne suis pas devenu Product Manager parce que j’aurais cessé d’aimer construire. Je le suis devenu parce que cinq ans passés à construire m’ont appris à voir ce qu’il fallait construire. Comprendre la technologie m’a permis de comprendre les produits. Comprendre les produits me permet aujourd’hui d’accompagner les équipes qui les construisent.
Et demain ?
Ce qui m’occupe l’esprit en ce moment.
Je cherche des sujets où la difficulté technique et l’enjeu utilisateur sont indissociables. C’est là que ce parcours sert à quelque chose.
- 01Produits techniques et outils pour développeurs
- 02Interfaces où la performance fait partie de l’expérience
- 03Systèmes complexes rendus simples à utiliser
- 04Équipes qui décident vite et bien
Fin du récit
On en parle ?
Une question sur ce parcours, un projet, une contradiction à m’opposer : les trois m’intéressent également. Et si vous êtes étudiant et que quelque chose ici vous parle, écrivez — c’est exactement comme ça que ça a commencé.