Michael Albert est CTO (Chief Technology Officer) de Dokeos depuis février 2026. Ingénieur passé par Bank of New York, Deloitte et Sortlist, il a refait le LMS Dokeos en 2018 en tant que prestataire externe avant d’en devenir CTO. Dans cette interview, il parle de son retour, de l’année du produit 2026 et de ce que l’IA change dans le développement.
Tu n’as pas le profil type d’un CTO : cheveux ébouriffés, planches de surf et guitare électrique en visio. Quel est le profil type du CTO ?
Dans le monde corporate, on imagine un CTO comme quelqu’un de senior, avec des pratiques bien établies, parfois un peu ancrées dans le passé. Dans une entreprise SaaS comme Dokeos, c’est différent. On est obligé d’avancer vite, d’apprendre, de s’adapter en permanence. On apprend sur le terrain, en s’inspirant de ce que d’autres ont déjà réalisé.
Mon rôle est de mettre toutes les ressources à disposition de l’équipe tech pour qu’elle atteigne ses objectifs. De donner des directions. Les ingénieurs font attention aux détails, moi je prends de la hauteur pour dire dans quelle direction on va et pourquoi : fiabilité des systèmes, résilience, sécurité, Developer Experience (DX) : ce sont des dimensions non fonctionnelles, invisibles pour les clients mais qui conditionnent tout le reste.
Et sur le plan humain, qui es-tu ?
Je suis ingénieur de formation, mais j’ai aussi un côté artistique. Je joue de la guitare, je fais de la skimboard avec ma fille. J’ai une sensibilité aux personnes assez forte. Ce n’est pas si courant dans le monde tech où on a tendance à valoriser l’expertise pure au détriment du reste. J’ai toujours pensé que les meilleures décisions techniques se prennent en comprenant les gens, ceux qui utilisent le produit, ceux qui le construisent.
« En 2018, j’ai dirigé l’équipe qui a réimaginé la plateforme LMS de fond en comble »
Qu’est-ce qui t’a amené chez Dokeos ? Raconte-nous ton riche parcours.
J’ai commencé ma carrière en tant que développeur chez Bank of New York à Bruxelles, le côté sexy en moins. Puis Deloitte. Enfin Belighted, une boîte de consultance en ingénierie, où j’ai rencontré l’équipe Dokeos pour la première fois. En 2018, j’ai dirigé l’équipe qui a réimaginé la plateforme LMS de fond en comble. L’ancien produit était très riche fonctionnellement, de la haute couture dans un sens. Mais dans le budget et les délais impartis, il était impossible de tout relivrer à l’identique. On avait dû réfléchir à repositionner ce nouveau produit : quel type de client on pouvait adresser, quelles fonctionnalités étaient vraiment nécessaires pour ce marché, et comment faire évoluer la plateforme à partir de là.
Et donc en 2026, qu’est-ce qui t’a convaincu de revenir chez Dokeos ?
J’ai immédiatement senti que je pouvais apporter quelque chose de concret. La raison numéro un, c’est vraiment ça : la certitude que je pouvais être utile. Je connaissais parfaitement les enjeux. Et puis le produit lui-même. Former des gens, toucher directement des personnes dans leur parcours professionnel, ça me parle. Ce n’est pas une plateforme de trading. Il y a une finalité humaine dans ce que l’on fait.
Mon retour a été particulier. Quand je suis arrivé, je connaissais déjà une bonne partie de l’équipe, Julien, Bertrand, Nicolas, Brahim. Les bureaux sont à Louvain-la-Neuve, là même où je travaillais avec Belighted. J’avais l’impression d’être déjà une vieille commode à la maison alors que ça faisait deux mois que j’étais là.
CTO versus Product Manager : la distinction n’est pas évidente pour tout le monde. Explique-nous la différence.
Ce sont deux rôles très différents. Le Product Manager s’intéresse aux problèmes des clients : quels sont les points de friction, qu’est-ce que la concurrence propose, comment on se démarque. Il capture les feedbacks, priorise, définit les objectifs, mesure les résultats. C’est un rôle orienté client, ancré dans le présent.
Le CTO prend plus de recul. Il s’assure que les grandes décisions techniques, architecture, infrastructure, sécurité, méthodologie, sont alignées avec les objectifs de l’entreprise à moyen et long terme. L’interaction entre les deux est constante : chaque évolution produit doit être interprétée techniquement. Combien de temps ça prend ? Quel impact sur les autres clients ? Est-ce qu’on le fait maintenant ou dans six mois ?
Une transformation radicale de la vision produit ?
En 2026, l’équipe Dokeos s’agrandit avec un nouveau CTO, un nouveau Frontend Tech Lead, Simon et une nouvelle Product Manager, Laura. C’est un grand changement chez Dokeos ?
Oui, en effet. Toute équipe technique qui grandit vite, passe par une phase où chacun travaille en silo. C’est normal. Ce qu’on construit maintenant, c’est la couche suivante : plus de vision partagée, plus d’entraide, une réflexion collective sur les solutions plutôt que l’exécution individuelle. Les bonnes idées peuvent venir de n’importe où dans l’équipe, mon rôle c’est de créer les conditions pour qu’elles émergent.
Simon apportera une vraie expertise UX et dans les techniques modernes de développement JS. Laura fera le lien entre le produit et les clients. Ce ne sont pas juste des recrutements, c’est une nouvelle façon de travailler ensemble.
« Des fondations solides et des innovations pensées pour les clients »
2026, l’année du produit. Concrètement, qu’est-ce que cela signifie ?
C’est une année d’investissement sur deux fronts simultanément. Côté technique, on travaille sur des fondations solides : infrastructure, résilience, plans de backup. Ce sont des chantiers invisibles pour les clients, mais qui conditionnent tout ce qu’on peut construire ensuite. Un client dans un environnement réglementé qui nous demande si on a un plan de disaster recovery et quand a été fait le dernier test, celui-ci a une réponse claire.
Côté produit, c’est une nouvelle façon de travailler. On part des interviews clients, pas pour construire une liste de fonctionnalités mais pour comprendre où sont vraiment les innovations à réaliser et les blocages à régler. Le reporting en est un bon exemple : on l’a rendu vraiment exploitable parce que c’est ce que les clients demandaient concrètement. Ce que je mesure après chaque livraison, c’est toujours la même chose : est-ce que ça a résolu le problème ? Si 80% des utilisateurs trouvent la nouvelle version meilleure, on peut avancer. Si on est à 40%, on creuse.
Je veux absolument éviter ce comportement » le CTO a dit ça, donc c’est ça »
L’IA change-t-elle la façon dont votre équipe développe ?
Profondément. Au tout début, les développeurs, moi inclus, se disaient qu’ils écrivaient du meilleur code que l’IA. Qu’elle pouvait aider à répondre à des questions, mais pas plus. Et puis à un moment, on a basculé. On a commencé à déléguer, d’abord prudemment, puis de plus en plus.
Aujourd’hui, quand j’ai une intuition sur une architecture mais que je ne suis pas certain, je demande à l’IA de me challenger. Je lui soumets mon hypothèse et je lui dis de me trouver les failles. Ça ouvre des alternatives, ça enrichit la discussion avec l’équipe. Et ça évite l’écueil du « le CTO a dit ça, donc c’est ça » ce que je veux absolument éviter.
Sur les revues de code, l’IA a parfois une pertinence impressionnante. Elle a une vue globale du code et peut identifier des impacts que le développeur n’avait pas vus. Ce n’est pas un remplacement, c’est une extension des capacités humaines.
Un mot sur l’hébergement européen, qui est souvent mis en avant mais rarement expliqué.
L’hébergement en Europe n’est pas une simple case à cocher RGPD. C’est un arbitrage réel entre sécurité, coût et disponibilité des services. Les grands clouds américains ont des capacités que les providers européens n’ont pas encore malheureusement. Et paradoxalement, certains systèmes hébergés en Europe ont connu plus d’incidents que des systèmes AWS bien configurés.
Notre position : hébergement européen par défaut, données chiffrées, et une architecture qui permet de répondre honnêtement aux questions d’audit. Ce n’est pas du marketing, c’est une contrainte opérationnelle réelle pour nos clients dans les secteurs réglementés.
