Interview de Tony, directeur technique

Tony, tu fêtes tes 11 ans chez Novius, qu'est-ce qui t'a amené ici et qu'est-ce que tu retrouves encore aujourd'hui qui te donne envie de rester ?

Je suis arrivé à Lyon en 2015 dans le but d’emménager avec ma femme (future femme à l’époque).

Je cherchais une agence digitale plus grande que la première où j’ai débuté (petite agence à Chambéry où nous étions 4). Novius a été le bon choix : j'y ai trouvé des profils techniques de haut niveau qui m'ont tiré vers le haut dès les premiers mois.

Onze ans plus tard, ce qui me donne envie de rester c'est un mix entre : des gens avec lesquels j'ai plaisir à travailler, des missions variées qui vont bien au-delà du code, et une confiance réelle dans la manière dont je peux faire évoluer les choses.

Tu es arrivé en tant que développeur et tu es aujourd'hui directeur technique : comment s'est construite cette évolution au fil des années ?

Petit à petit ! Quand je suis arrivé chez Novius, j'avais un profil assez polyvalent : c'est l'avantage de démarrer dans une petite structure, on touche à tout et c'est extrêmement formateur. J'ai donc intégré une équipe de développeurs en tant que full-stack. Ce qui a accéléré ma progression, c'est que les lead devs de l'équipe et le directeur technique de l'époque avaient un très bon niveau technique. J'ai pu apprendre énormément à leur côté.

Au fil des années, j'ai pris le rôle de lead développeur, avec la responsabilité de piloter des projets de plus grande envergure. Puis, quatre ans après mon arrivée, l'opportunité de devenir directeur technique s'est présentée alors je l’ai saisie.

Concrètement, quel est le rôle du directeur technique dans une agence web ? Quelle place as-tu chez Novius ?

Au quotidien, j'interviens de manière transversale chez Novius. Mes missions principales s'articulent autour de quatre axes :

• le management et la montée en compétences de l'équipe de développement ;
• le pilotage de la R&D (Recherche et Développement) et les choix technologiques de l'agence ;
• l'accompagnement des chefs de projet sur les aspects techniques les plus complexes (architecture, spécifications, arbitrages) ;
• et enfin la construction des budgets et des propositions techniques durant les phases d'avant-vente.

À quel moment interviens-tu dans un projet et quel est ton rôle à chaque étape ?

J'interviens principalement en amont des projets, durant la phase de spécifications techniques. C'est le moment où l'on pose les fondations : choix d'architecture, découpage fonctionnel, identification des points de complexité. Il m'arrive également d'animer des ateliers de conception directement avec les clients, notamment quand le sujet demande des arbitrages techniques structurants.

Une fois le projet en phase de réalisation, je passe en support auprès des développeurs : revues de code sur les points les plus critiques, déblocages techniques, validation des choix d'implémentation. Et selon les projets, je participe aussi aux comités de pilotage pour apporter la vision technique aux échanges avec le client.

Comment assures-tu la cohérence technique entre les différents projets menés en parallèle chez Novius ?

La cohérence technique, ça commence par une conviction forte : on ne s'éparpille pas. Chez Novius, on ne court pas après chaque framework à la mode. On a fait des choix technologiques assumés, sur des solutions pérennes, et on investit pour en devenir experts. C'est ce qui nous permet de garantir un niveau de qualité constant d'un projet à l'autre.

Concrètement, on capitalise sur des briques communes entre nos projets : des composants open-source que l'on maintient, des socles mutualisés par stack technique. Quand un développeur passe d'un projet à un autre, il retrouve les mêmes fondations, les mêmes conventions, les mêmes standards. Ça réduit la courbe d'apprentissage et ça sécurise la maintenabilité sur le long terme.

Qu'est-ce qui te challenge le plus dans ton poste aujourd'hui ?

Sans surprise, depuis quelque temps maintenant, c'est l'arrivée de l'IA. Le sujet est structurant parce qu'il nous challenge sur deux fronts en parallèle.

D'abord sur ce que l'on propose à nos clients : comment intégrer l'IA de manière pertinente dans les solutions que l'on conçoit, sans tomber dans l'effet gadget. Ensuite sur notre manière de produire : l'IA transforme nos workflows de développement, nos méthodes de travail, notre façon de spécifier et de coder.

Le vrai défi, c'est de ne pas subir cette transformation mais de la piloter, en gardant notre exigence de qualité et en s'assurant que l'équipe monte en compétences de manière homogène.

Le web a radicalement changé, quelle est la transformation qui t'a le plus marqué ?

J’ai surtout connu l'arrivée du responsive et la montée en puissance des frameworks JavaScript. Tout cela a changé notre façon de travailler, mais pas la nature de ce que l'on fait.

Avec l'IA, la question est différente : elle touche à la manière dont on pense, dont on conçoit, dont on produit. C'est à la fois stimulant et très intense : tout évolue encore beaucoup d'un mois à l’autre. Le vrai défi c'est de rester lucide dans cette accélération permanente.

Quelle est ta position sur l'utilisation de l'IA comme outil d'aide au développement ? Opportunité ou risque ?

Opportunité, sans hésiter. Mais pas dans le sens où beaucoup l'entendent. Pour moi, le premier apport de l'IA, ce n'est pas de générer du code plus vite. C'est de gagner en rigueur sur tout ce qui entoure le code : des spécifications plus complètes, des documentations mieux structurées, des revues de code plus systématiques.

Ce sont des sujets sur lesquels on sait collectivement qu'on devrait faire mieux, mais où le temps manque toujours. L'IA nous donne un levier concret pour réhausser ce niveau d'exigence. Après, il faut rester pragmatique : l'IA est un outil, pas un développeur. Elle ne remplace ni l'expertise métier, ni la capacité à prendre des décisions d'architecture. Le risque, il n'est pas dans l'outil lui-même, il est dans la tentation de lui déléguer la réflexion.

Quels conseils donnerais-tu à quelqu'un qui souhaite évoluer vers un rôle de directeur technique ?

Le premier conseil, c'est la curiosité. Pas uniquement la curiosité technique, même si elle est indispensable. Je parle d'une curiosité large : comprendre les enjeux business d'un client, s'intéresser à la gestion de projet, savoir lire un budget. Un CTO (Chief Technical Officer) qui ne parle que de code, c'est un lead dev avec un autre titre.

Le deuxième, c'est d'accepter que la polyvalence est une force, pas une faiblesse. Dans notre métier, on valorise souvent l'expertise pointue sur une technologie. Mais le rôle du directeur technique demande l'inverse : avoir une vision suffisamment large pour arbitrer, connecter les sujets entre eux, comprendre les contraintes de chacun.

Et le troisième, c'est de ne pas attendre le titre pour adopter la posture. Prendre du recul sur un projet, challenger une spécification, s'intéresser à l'avant-vente : tout cela se fait bien avant d'avoir le poste.

En dehors du code, quels sont tes centres d'intérêt ou ce qui t'inspire au quotidien ?

En dehors du travail, ce qui compte le plus c'est le temps passé avec ma famille et mes amis. C'est aussi ce qui me permet de décrocher vraiment. Je fais du sport régulièrement, j'en ai besoin pour garder un bon équilibre. Je suis pâtissier à mes heures perdues : j'aime me challenger avec des recettes complexes. Mais le vrai plaisir c'est le moment où tu poses le gâteau sur la table et que tout le monde se régale !