Questions fréquentes

Comment testez-vous ?🔗

Sur les projets neufs

Sur les projets neufs, je pratique TDD. C’est pour moi une condition de la qualité du logiciel, et donc un principe auquel je ne déroge que dans de rares cas, notamment lorsqu’il s’agit de dette technique assumée.

Plus précisément, je pratique un Outside-In Diamond TDD mâtiné de BDD. Je pars du comportement attendu du logiciel pour descendre progressivement vers les détails d’implémentation. Cette approche donne davantage de place aux tests fonctionnels et d’acceptation que la traditionnelle pyramide de tests, dont l’usage systématique a parfois conduit la profession à tester davantage le code que le logiciel.

Les tests d’acceptation sont mon pain quotidien. Ils décrivent, dans un langage compréhensible par les deux parties, les comportements attendus du logiciel. Je les construis avec vous et les reprends régulièrement afin de vérifier que j’ai bien compris votre besoin.

Les tests contractuels et d’intégration vérifient ensuite les interactions entre les différentes parties du logiciel et avec ses dépendances. Ils constituent les clauses techniques de notre contrat : ils permettent de vérifier que ce qui a été livré correspond bien à ce qui avait été convenu.

Les tests de plus haut niveau, comme les tests de fumée ou end-to-end, vérifient que le logiciel fonctionne réellement lorsqu’il rencontre le monde extérieur. Ils peuvent également servir de démonstration lors de la livraison d’une itération.

Je ne suis évidemment pas opposé aux tests unitaires. Ils sont simplement utilisés avec discernement. Trop nombreux ou trop liés à l’implémentation, ils peuvent rigidifier le code et rendre les évolutions pénibles. Je les réserve notamment aux parties où la manière de procéder compte autant que le résultat : algorithmes, performances, cryptographie, calculs complexes, etc.

Sur les logiciels legacy

Je reprends ici la définition de Michael Feathers : le code legacy, c’est du code non testé que l’on ne peut pas simplement jeter. Lorsqu’on me confie un tel logiciel, je ne promets pas de le rendre propre du jour au lendemain. Sauf budget colossal, ce serait une promesse peu crédible.

Tout code nouveau ou modifié est en revanche testé comme du code neuf. Pour le code existant, je commence par construire un filet de sécurité adapté : des tests plus grossiers, notamment des tests de fumée, qui permettent de réduire progressivement le risque. Leur niveau dépend de vos besoins, du niveau de confiance recherché et du budget disponible.

Une fois le logiciel sécurisé, son assainissement peut se faire progressivement. Un budget de maintenance peut être consacré à cette réduction de la dette technique. Ce n’est pas de l’argent dépensé pour faire joli : c’est le prix à payer pour que le logiciel continue à évoluer lorsque votre métier, lui, ne cesse de changer.

En cas de défaut

Lorsqu’un bug est découvert, je cherche à faire en sorte qu’il ne puisse pas revenir. J’écris d’abord un test qui reproduit le défaut, puis je modifie le code pour faire passer ce test. Le test reste ensuite dans la suite de non-régression.

Je peux ainsi garantir quelque chose de précis : un bug corrigé ne reviendra pas sous la même forme sans que les tests ne le détectent. C’est beaucoup plus utile qu’une promesse vague de logiciel « sans bugs ».

Quelles sont vos sources ?🔗

La formation initiale d’un développeur devient rapidement insuffisante. Je considère donc que la formation continue devrait être une obligation pour notre profession. Je commence naturellement par me l’appliquer à moi-même.

Pour entretenir et faire progresser ma pratique, je m’appuie principalement sur trois sources :

• Les ouvrages des maîtres de la profession, pour transmettre l’expérience accumulée et les idées qui ont résisté au temps.
• La littérature scientifique, pour confronter les pratiques aux connaissances produites par la recherche.
• L’expérience, pour éprouver ces idées dans la réalité et apprendre de ce qui fonctionne ou échoue.

Je cherche autant que possible à remonter à la source plutôt qu’à suivre les modes. La littérature scientifique apporte de nouveaux résultats, les ouvrages permettent de prendre du recul et la pratique rappelle que tout ne se passe pas comme dans un article.

Je ne fais en revanche pas des normes payantes une source de connaissances. Le principe même de devoir payer pour accéder à une norme qui prétend faire autorité dans une profession me paraît profondément problématique. La connaissance professionnelle devrait pouvoir être discutée, vérifiée et transmise, pas gardée derrière un péage.

Cette démarche permet aussi de limiter mes propres biais, notamment celui qui consiste à chercher uniquement les informations confirmant ce que je crois déjà. Lorsque j’interviens chez vous, vous pouvez donc me demander d’où vient une pratique que je vous recommande. Je serai généralement heureux de vous donner la référence.

Pouvez-vous baisser vos standards pour respecter mes délais ?🔗

Je peux adapter mes standards à votre besoin et à vos contraintes de délai. La qualité n’est cependant pas un dogme : elle consiste à faire les bons choix au regard de l’usage et de la durée de vie attendue du logiciel.

Il faut notamment distinguer trois situations :

• les prototypes ;
• les logiciels one shot ;
• la dette technique.

Un prototype sert à apprendre avant de construire. Il peut s’agir d’une démonstration, d’un POC ou d’un moyen de vérifier une hypothèse. Dans ce cas, il peut être pertinent de privilégier la vitesse et de sacrifier une partie des qualités que j’exigerais d’un logiciel destiné à durer.

Un prototype n’est toutefois pas un produit fini. Je considère qu’il doit rester clairement identifié comme tel et ne pas être déployé en production sans avoir été repris. Son objectif est de sécuriser une décision future, pas de devenir par accident le logiciel définitif.

Un logiciel one shot est, lui, conçu dès le départ pour ne pas durer. Un convertisseur de données utilisé une seule fois ou une moulinette de migration n’a pas les mêmes exigences qu’un logiciel métier appelé à fonctionner pendant dix ans. Je peux donc adapter le niveau d’investissement à cette durée de vie. En revanche, un tel logiciel n’a pas vocation à faire ensuite l’objet d’un contrat de maintenance classique.

La dette technique est différente. Il s’agit de faire consciemment un choix qui rendra le logiciel plus difficile à faire évoluer plus tard, généralement pour obtenir une fonctionnalité plus rapidement aujourd’hui. Cela peut être un choix parfaitement rationnel lorsque le délai est réellement prioritaire.

Je peux donc accepter de contracter une dette technique avec vous, à condition qu’elle soit identifiée et que nous sachions ce qu’elle implique. Une dette non déclarée finit facilement par devenir une contrainte permanente. Je préfère que nous sachions ensemble ce que nous gagnons aujourd’hui et ce que nous devrons payer demain.

En revanche, je ne crois pas qu’un délai puisse justifier n’importe quel compromis. Mon rôle est aussi de vous aider à distinguer ce qui peut être différé de ce qui mettrait réellement le logiciel en danger.

Quelle est votre définition de la qualité ?🔗

Un logiciel de qualité est d’abord un logiciel qui rend correctement le service attendu. Mon rôle de professionnel est de faire en sorte qu’il continue à le faire dans le temps, que nous travaillions encore ensemble ou non.

Pour un bâtiment ou un véhicule, la qualité tient notamment à sa capacité à conserver sa fonction, à être entretenu et à être réparé. Un logiciel est différent : son environnement change constamment et son rôle est souvent amené à évoluer avec lui. Le métier de votre entreprise change, ses utilisateurs apprennent, ses contraintes évoluent et de nouveaux besoins apparaissent.

La qualité d’un logiciel ne consiste donc pas seulement à faire fonctionner correctement ce qui a été demandé aujourd’hui. Elle réside aussi dans sa capacité à accueillir les changements de demain. Un logiciel difficile à comprendre ou à modifier peut être parfaitement fonctionnel aujourd’hui tout en étant déjà de mauvaise qualité.

Roy Osherove décrit la programmation comme l’art de bâtir des châteaux de vent. Hunt et Thomas parlent plutôt de l’art de recueillir et de formaliser des connaissances. Ces deux approches rappellent une même chose : le logiciel n’est pas un objet figé. Il est une construction qui doit pouvoir être comprise, corrigée et transformée.

C’est pourquoi j’accorde autant d’importance à la maintenabilité. Un logiciel de qualité laisse aux personnes qui le reprendront demain la possibilité de comprendre ce qu’il fait, pourquoi il le fait et comment le faire évoluer. Pour moi, le travail bien fait consiste précisément à construire cette capacité de changement.

Pratiquez-vous la cybersécurité ?🔗

La cybersécurité est bien trop vaste pour que quiconque puisse sérieusement prétendre en avoir fait le tour. Je suis développeur : ma responsabilité dans cet écosystème est avant tout de produire du logiciel sécurisé. C’est dans ce domaine que je peux vous apporter une véritable compétence.

J’intègre la sécurité dès la conception et dans le développement du logiciel. Les analyseurs statiques (SAST) font partie de mon outillage, même si je reste prudent quant à leur usage : leur capacité à produire des alertes ne garantit pas leur capacité à produire de l’information utile. J’utilise également des tests de vulnérabilité et me forme progressivement aux outils d’analyse dynamique (DAST).

Je suis également réservé sur l’usage systématique des outils d’analyse des dépendances (SCA). Leur rapport signal/bruit peut être médiocre et détourner l’attention des véritables risques. Je préfère souvent commencer par une lecture attentive du code et un typage strict, qui permettent de prévenir directement certaines classes de défauts.

Enfin, mon parcours de développeur et ma formation en Intelligence Économique m’ont apporté de bonnes bases en hygiène numérique et en sécurité des systèmes et réseaux à petite échelle. Cela me permet de prendre en compte le contexte dans lequel votre logiciel sera exploité, mais je ne prétends évidemment pas remplacer un spécialiste de la cybersécurité lorsque les enjeux dépassent mon domaine.

Avec quels langages travaillez-vous ?🔗

Réponse courte : C#/.NET est ma plateforme de prédilection. Je travaille également avec PHP et TypeScript/Node.js.

Réponse longue : les langages sont mes outils, pas mon identité. Je choisis celui qui me paraît adapté au problème et au contexte du projet.

• C#/.NET : 14 ans de pratique, mon environnement de prédilection.
• PHP : 6 ans de pratique.
• TypeScript/Node.js : 3 ans de pratique.
• Java et C++ : je les ai pratiqués, mais ils sont aujourd’hui un peu rouillés.
• Python : je l’utilise principalement pour mes formations.

Cette liste n'est pas une liste de compétences commerciales : je ne souhaite pas que le choix d'un langage devienne le sujet principal avant même que nous ayons compris votre problème. Si le projet nécessite un langage que je connais moins bien, je peux naturellement me remettre à niveau. Le temps nécessaire sera simplement pris en compte dans le planning, sans coût caché de « formation » reporté sur le client.

Êtes-vous compétent en Front-End ?🔗

Ce site pourrait servir de réponse. Il est fonctionnel, sobre, et peut-être même un peu trop sobre.

Je sais concevoir et développer des interfaces web simples et efficaces, mais mes talents en UI/UX s’arrêtent là. Je ne vais pas vous promettre une expertise en design d’interface si ce n’est pas mon métier.

Si votre projet nécessite des compétences plus poussées en Front-End, je connais de très bons développeurs spécialisés dans ce domaine que je peux vous recommander. Je préfère m’entourer de personnes compétentes plutôt que de prétendre savoir tout faire.

Qu'entendez-vous par « Pas de régie » ?🔗

« Pas de régie » ne signifie pas « jamais chez le client ». Je peux travailler sur site lorsque le projet le justifie, mais je ne vends pas ma présence permanente dans vos locaux. J’explique ici pourquoi.

Plus une mission s’inscrit dans la durée, plus elle doit me laisser de l’autonomie. Une mission courte peut être réalisée largement sur site. Pour une mission plus longue, je privilégie une organisation à distance, avec un déplacement sur site au maximum toutes les deux semaines. Des déplacements plus fréquents peuvent ponctuellement se justifier par une phase particulière du projet, mais restent exceptionnels.

Je suis un professionnel indépendant, pas un salarié mis à disposition. Nous nous accordons sur le travail à réaliser, les échéances et les éventuels jalons, mais je reste autonome dans l’organisation de mon activité, de mes horaires et de mon lieu de travail. Cette autonomie fait partie intégrante de notre relation contractuelle.

Ce n’est d’ailleurs pas qu’une question de préférence personnelle : lorsqu’un prestataire est utilisé dans les faits comme un salarié, l’indépendance devient difficile à défendre et la relation peut être requalifiée en contrat de travail. Aucun d'entre nous ne souhaite cela.

Ce fonctionnement permet également à l’Atelier de continuer à travailler pour plusieurs clients. Je peux consacrer une part importante de mon temps à une mission de développement pendant quelques semaines ou quelques mois, mais je ne peux pas être durablement intégré à temps plein dans une équipe comme le serait un salarié.

En bref, je vous demande simplement que la prestation reste une prestation indépendante, dans le respect du cadre applicable aux travailleurs indépendants. C’est une condition nécessaire à la relation que je souhaite construire avec mes clients.

J'ai déjà réalisé une estimation de temps, la respecterez-vous ?🔗

Une estimation n’est pas une promesse. Elle peut donner un ordre de grandeur utile pour décider si un projet est envisageable, mais elle ne permet pas de connaître à l’avance la durée exacte d’un développement.

Un projet logiciel doit en permanence arbitrer entre quatre variables : le temps, le coût, la qualité et le périmètre. Mes ressources sont limitées et je ne souhaite pas sacrifier la qualité pour tenir artificiellement une échéance. Il reste donc principalement deux variables sur lesquelles nous pouvons jouer ensemble : le délai et le périmètre.

Si vous avez une échéance à respecter, je peux m’engager sur cette date avec un logiciel fonctionnel apportant de la valeur. En revanche, nous devons accepter que certaines fonctionnalités soient reportées ou abandonnées. Le périmètre devient la variable d’ajustement.

Si le périmètre est lui-même fixé, je peux fournir une estimation du temps nécessaire et de son coût, mais pas garantir qu’ils seront respectés au jour ou à l’euro près. Plus un projet est long ou complexe, plus l’incertitude augmente.

Dans les deux cas, je cherche à réduire cette incertitude en livrant régulièrement et en vous donnant une visibilité concrète sur l’avancement. Nous pouvons alors réévaluer le périmètre à mesure que le projet progresse, plutôt que découvrir à la fin que l’estimation initiale était erronée.

Je m’engage surtout à être transparent sur ce que je sais, ce que j’ignore et ce qui a changé. Mon rôle est de vous aider à arbitrer entre délai, coût, qualité et périmètre, afin que les décisions prises restent les plus sûres possibles pour votre projet.

Je travaille en cycle en V, peut-on s'entendre ?🔗

Oui. Je peux travailler dans une organisation qui utilise un cycle en V, à condition de pouvoir conserver une démarche itérative dans mon travail.

Un projet logiciel évolue nécessairement en cours de route. Le métier continue pendant le développement, les utilisateurs précisent leurs besoins et le logiciel lui-même fait apparaître des questions que personne ne pouvait anticiper au départ. Il m’arrive également de proposer des améliorations lorsque le développement fait apparaître une meilleure manière de répondre au besoin.

Je peux donc m'adapter à un cadre projet en V, à condition que celui-ci n'interdise pas ces ajustements. De mon côté, je travaille par itérations courtes et cherche à produire régulièrement quelque chose de fonctionnel. Vous pouvez ainsi suivre l'avancement du logiciel au fur et à mesure et intégrer ces livraisons à votre propre processus de validation.

Cette manière de travailler suppose que je puisse échanger régulièrement avec un référent métier capable de répondre aux questions que les spécifications ne peuvent pas prévoir. Les tests automatisés jouent également un rôle important : ils précisent le comportement attendu du logiciel et servent de garde-fou lorsque celui-ci évolue. Votre expert métier doit donc pouvoir les valider.

Je préfère être clair sur ces conditions. Je ne peux pas garantir la qualité d'un logiciel dans un environnement où les besoins sont entièrement figés à l'avance et où aucun échange avec le métier n'est possible. Laisser une place à l'apprentissage et à l'itération n'est pas, pour moi, une méthode particulière de gestion de projet : c'est une condition du travail bien fait.

Travaillez-vous sur site ou à distance ?🔗

TLDR; Le lieu de travail dépend de la nature de l’intervention. Voici les modalités habituelles :

L’Atelier est avant tout mon lieu de travail. J’y passe la majorité de mon temps à façonner des logiciels, dans un environnement que j’ai adapté à mon métier. Le développement demande de longues périodes de concentration et un environnement stable ; c’est dans ces conditions que je produis le meilleur travail.

La présence sur site reste néanmoins précieuse lorsque la nature du travail le justifie. C’est notamment le cas des audits : comprendre un logiciel nécessite de comprendre les personnes qui le produisent et l’utilisent, ainsi que l’organisation dans laquelle il s’inscrit. Je ne me contente donc pas de lire le code.

Pour les missions de développement en régie, je privilégie une organisation à distance, avec un déplacement sur site au maximum toutes les deux semaines. Des déplacements plus fréquents peuvent ponctuellement se justifier lors d’une phase particulière du projet, mais restent exceptionnels. J’explique ici les raisons de ce choix.

Quelles prestations proposez-vous aux établissements de formation ?🔗

Mon intervention ne s’arrête pas nécessairement aux heures de cours. Les établissements avec lesquels je travaille peuvent également me solliciter pour des jurys, soutenances ou suivis de mémoires professionnels.

Je peux également intervenir auprès d’un établissement dans lequel je n’enseigne pas, à condition que le sujet relève de mon domaine de compétence. Je peux notamment accompagner les apprenants dans leurs travaux de recherche ou leurs projets professionnels, en m’appuyant sur ma veille et sur la littérature scientifique.

C’est aussi l’occasion de transmettre une autre manière d’apprendre le métier : partir des sources, confronter les idées à la recherche et développer progressivement son propre jugement professionnel.

Où enseignez-vous ?🔗

Partout en France, tant que l’établissement prend en charge les frais de déplacement et d’hébergement lorsque c’est nécessaire. Je me déplace volontiers pour enseigner, mais je demande aux responsables pédagogiques de regrouper autant que possible les cours afin d’éviter les allers-retours inutiles.

Pour les formations, je privilégie le présentiel. Les cours magistraux comme le lancement des travaux pratiques, exercices et katas se font sur place. Leur suivi peut ensuite être réalisé à distance, notamment lorsque les apprenants travaillent sur un projet pendant plusieurs semaines.

Pour les formations professionnelles, le présentiel me paraît presque indispensable. Sortir les participants de leur environnement de travail habituel les aide à prendre du recul et à consacrer réellement du temps à l’apprentissage, plutôt qu’à essayer de suivre une formation entre deux réunions.

J’ai notamment enseigné à Arras, Toulouse, Montpellier, Lyon, Nantes et Bordeaux.

Quels sont vos tarifs ?🔗

Pour du développement classique, comptez autour de 560 € par jour. Ce tarif constitue un ordre de grandeur : le prix d’une prestation dépend de sa nature, de sa complexité, de l’état du logiciel lorsqu’il s’agit d’une reprise, de sa durée et des éventuels déplacements.

Les audits, formations et autres prestations font l’objet d’une tarification adaptée à leur nature. Les devis sont gratuits et sans engagement : contactez-moi pour en discuter.

Do you speak English?🔗

Yes. We can work in English for software development, both in writing and in conversation. I am comfortable discussing technical matters with English-speaking developers and clients.

I am not yet comfortable providing training or conducting audits entirely in English. These activities require a much finer understanding of implicit meanings, context and nuance than day-to-day software development.

I am actively working on improving my English and plan to spend several months in an English-speaking country to take it further. Training and auditing in English are therefore services I hope to offer in the future.