Cette FAQ répond aux questions les plus fréquentes de nos clients. Cette partie se veut pédagogique et explicative. Nous souhaitons vous faire comprendre notre manière de travailler et son intérêt pour votre entreprise.
Si votre question n'est pas écrite, ou que la réponse vous laisse sur votre faim, contactez-nous, nous répondrons avec joie.
Pour tous les projets neufs, je pratique TDD, qui n'est pas un élément négociable (sauf rares cas). Plus précisément, je pratique Outside-In Diamond TDD, qui offre une plus grande souplesse que la traditionnelle pyramide de tests, qui doit être désapprise par la profession.
Notre pain quotidien, c'est le test d'acceptation isolé ou test fonctionnel. Il détaille les clauses du contrat que nous avons passé ensemble en de multiples affirmations que je reprendrai périodiquement avec vous afin de m'assurer d'avoir bien cerné votre besoin.
Les tests contractuels ou d'intégration, décrivent le comportement que nous avons fixé ensemble au début d'une itération. Je leur donne une valeur juridique, ces tests valident la conformité des travaux à votre demande initiale.
Les tests de plus haut niveau (smoke tests, end-to-end tests) viennent démontrer le bon fonctionnement de la solution en interaction avec le monde extérieur. Ils me servent également de démonstration, lorsque je vous livre une itération.
Je ne suis pas contre l'utilisation de tests plus fins, comme les tests unitaires. Ils ont hélas été trop utilisés par une partie de la profession, provoquant la rigidification du code et dégoûtant une partie des développeurs de l'écriture de tests. Aussi, je les utilise que sur des parties critiques du code, où la manière de procéder importe autant que le résultat obtenu (performances, algorithme précis, cryptographie, etc.).
Sur les projets legacy
J'adopte la définition de Michael Feathers. Le Code Legacy est tout code non-testé qui m'est confié sans pouvoir partir rapidement à la poubelle. Dans les cas où j'accepte de reprendre un tel code, il est exclu, sauf si votre budget est colossal, de l'assainir complètement d'un coup. Le code ajouté ou modifié sera testé comme du code neuf. Le code préexistant sera sécurisé à l'aide de tests plus grossiers (smoke test) selon vos besoins, le niveau de confiance que vous souhaitez et votre budget.
Une fois repris et étayé, votre code devra être progressivement assaini. Un budget mensuel devra être établi à ce titre, il ne servira qu'à réduire l'endettement de votre application, donc à faciliter les développements futurs. Un bon budget de maintenance représente une charge non-négligeable sans pour autant gréver votre rentabilité. Il n'est pas de l'argent investi à perte, mais bien la garantie que le logiciel dans lequel vous avez investi tant d'efforts ne décède pas un beau matin, trop endetté pour pouvoir évoluer au rythme de vos besoins.
En cas de défaut
Je garantis qu'aucun bug ne reviendra après sa résolution. Pour cela j'utilise les tests de défaut. Pour chaque bug constaté, un test est écrit afin de le reproduire. Puis le code est modifié afin de faire passer ce test. Ainsi le bug corrigé ne peut pas revenir sous cette forme sans que je n'en sois informé.
Si pour vous, surqualité signifie "fonctionnalité payée, mais non demandée", la pratique de TDD nous en préserve. Nous écrivons ensemble les tests qui définissent le comportement votre logiciel. De retour à l'atelier, nous écrivons le code minimal capable de faire passer ces tests. La simplicité est notre maître mot.
La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer.
Antoine de Saint-Exupéry dans Terre des hommes
La surqualité peut également désigner un code "trop propre" dans la bouche de certaines personnes. Nous avons fait il y a longtemps de deuil du code parfait, qui n'existe pas. En revanche, nous ignorons ce que signifie un code "trop propre". Un code propre est un code ayant une réponse optimale au changement. Un code peut s'encrasser et réduire la vélocité des développeurs. L'existence du cas inverse est hypothétique.
Un code "trop propre", si une telle chose est possible, serait donc un code qui facileterait au-delà du raisonnable son édition future ? Nous le prenons comme une bonne nouvelle, pas comme de la surqualité.
La formation initiale d'un développeur est très vite caduque. Nous défendons l'obligation de formation continue pour l'ensemble de notre profession, donc nous commencons par nous l'appliquer à nous mêmes.
Trois sources permettent à l'Atelier de proposer les pratiques les plus reconnues :
Les ouvrages de maîtres de la professions, socle impérissable.
La littérature scientifique, étai des connaissances.
L'expérience, notre maîtresse en artisanat.
Ces trois sources mêlent actualité brûlante et prise de recul, sujets à la mode et validation des acquis, confirmation de nos pratiques et armes contre le biais de confirmation. Lorsque nous intervenons chez vous, vous avez le droit de nous demander nos sources.
Pouvez-vous baisser vos standards pour respecter mes délais ?🔗
Nos standards sont des garde-fous, pas un dogme. Nous passons outre dans certains cas :
Les prototypes.
Les logiciels one shot.
La dette technique.
Un prototype est un logiciel Quick&Dirty permettant de réaliser une démonstration, un POC ou de tester une hypothèse avant la réalisation d'un vrai logiciel. De même que vous ne prendriez pas la route au volant d'un concept car, nous interdisons contractuellement à nos clients de déployer en production un prototype. Ils ne doivent servir qu'à sécuriser vos choix futurs. Un logiciel prototype ne respecte aucun standard de qualité ou de sécurité, donc il peut être produit très rapidement pour un coût modeste. L'équivalent dans l'automobile est le modèle de terre cuite qui sert aux premiers essais en soufflerie. Il permet de valider le dessin final, mais ne roulera jamais.
Un logiciel one shot est un morceau de code qui n'est pas destiné à durer dans le temps. Il est produit pour un but précis, avec une date d'expiration définie à l'avance, dont dépendront les standards de qualité. Les cas les plus fréquents sont les convertisseurs de données ou "moulinettes", servant le temps d'une migration. Nous produisons de tels logiciels, mais refuserons tout contrat de maintenance ultérieur à leur sujet.
La dette technique concerne les logiciels que nous développons déjà à vos côtés. Elle consiste à accélérer le développement d'une fonctionnalité dont vous avez besoin rapidement, contre un temps plus long de "réparation" ensuite. La dette technique est similaire à la dette monétaire. Nous ne prêtons que temporairement, pour un temps défini à l'avance. Une dette ne peut pas servir à en couvrir une autre. Contracter une dette implique des intérêts. En d'autres termes, nous pouvons temporairement produire plus vite, au prix d'une "blessure" dans le code qui handicapera les développements futurs tant qu'elle n'est pas soignée. Soigner la blessure prend plus de temps qu'il n'en aurait fallu pour réaliser les choses proprement dès le départ. En bref, la dette technique vous permet de raccourcir le délai de livraison d'une fonctionnalité, en échange d'un temps de "repos" plus tard.
Un logiciel de qualité est un logiciel qui vous satisfait. Notre tâche en tant que professionnels est de bâtir des logiciels qui répondront à ce critère tout au long de leur durée de vie, que nous travaillions encore ensemble ou non. Lorsque l'on parle de qualité pour un bâtiment ou un véhicule, on s'attend à quelque chose qui puisse conserver sa fonction initiale le plus longtemps possible. Un bâtiment de qualité est durable et réparable. Le monde du logiciel n'obéit pas aux mêmes lois.
Le développeur Roy Osherove disait de la programmation informatique qu'elle est l'art de bâtir des châteaux de vent. Hunt&Thomas parlent plus volontiers de l'art de recueillir et formaliser des connaissances. Les deux définitions portent le même message : un code de qualité n'est pas de marbre, il est au contraire le plus perméable au changement possible. Votre métier évolue sans cesse, vos connaissances s'affinent, votre stratégie doit répondre aux enjeux mouvants d'un monde en perpétuel mouvement. Un bon logiciel ne freine pas ces processus naturels, mais s'y adapte. Voici pour nous l'enjeu de la qualité logicielle.
La cybersécurité est bien trop vaste pour que quiconque puisse claironner qu'il en a fait le tour. Je suis développeur et mon rôle dans ce vaste écosystème est de livrer du code sécurisé. Je suis donc compétent en sécurité du code.
Les analyseurs statiques font partie de mon outillage (SAST) mais j'ai tendance à m'en méfier pour des raisons exposées dans ma veille. J'utilise les tests de vulnérabilité, ancêtres manuels des outils DAST, en attendant de me former à ces derniers.
J'ai tendance à privilégier une lecture du code et un typage sévère à l'usage d'outils de SCA, tant les versions actuellement sur le marché sont verbeuses et peu utiles à mon sens.
J'ai enfin des compétences en hygiène numérique, issues autant de mon parcours de geek que de ma formation en Intelligence Economique. Je peux faire de la sécurité des systèmes et réseaux à très petite échelle.
Réponse courte : tout est possible, mais .NET est notre plateforme de prédilection.
Réponse longue : nous préférons les langages orientés objet de haut niveau. Java, C#, C++ ou PHP nous sont familiers. Nous n'avons pas souhaité inclure cette liste dans notre présentation générale pour ne pas focaliser nos clients sur ce point. Les langages sont nos outils, nous utilisons le plus adapté pour chaque problème. Si nous devons nous mettre à niveau sur un langage, les délais avant livraison s'allongeront de manière transparente, il n'y aura pas de coût caché de formation à votre charge.
Ce site pourrait servir de réponse. Il est fonctionnel et sobre, peut-être trop sobre d'ailleurs. Nous pouvons élaborer des interfaces simples, mais nos talents en UI/UX s'arrêtent là. Nous pouvons cependant collaborer avec un intégrateur ou un développeur spécialisé dans les interfaces graphiques si vos besoins dépassent nos compétences.
Pour l'expliquer autrement, plus une mission s'étale dans le temps, plus nous exigerons d'autonomie. Les missions courtes (1 mois ou moins) en présentiel sont possibles, mais au-delà, le présentiel devra se raréfier.
Comprenez également que nous ne sommes pas des prestataires. L'indépendance n'est pas qu'une affaire de lieu de travail, mais également une autonomie en matière d'horaires et de calendrier. Sauf impératif (réunion, formation, livraison, etc.), nous ne rendons de compte à personne concernant notre agenda, seule la date de livraison que nous avons négociée et les jalons nous sont opposables.
Nous servons en règle générale plusieurs clients à la fois : un seul client en développement (l'activité est prenante), mais une multitude en conseil, formation, maintenance et autres activités. Nous ne pouvons pas nous permettre d'être bloqués à 100% plus de quelques semaines.
Ce schéma est une bonne représentation de ce qu'il est possible de faire. Une mission ne peut pas pas être à la fois plein-temps, sur site et long-terme. Les missions que vous nous proposez doivent s'inscrire dans ce triangle. Par exemple :
En jaune, la mission Méritis SIRH était moyenne-durée, occasionnellement sur site, à 2/3 temps en raison de formations planifiées sur la période.
En rouge, la mission OxaControle dure depuis près de 3 ans à la fois sur chantier et en remote, mais en pointillés très espacés.
En bleu, les formations en école sont récurrentes chaque année et presque totalement en présentiel, mais de courte durée (quelques jours à 2 semaines) et à temps partiel (ces journées/semaines sont rarement remplies intégralement).
En vert, le développement du Pont SEPA-Chargebee était presque à plein temps pour tenir les délais. Je ne me suis pas déplacé du tout sur site. La mission a duré 3 mois ½ au total.
J'ai déjà réalisé une estimation de temps, la respecterez-vous ?🔗
Tout projet est défini par quatre variables : le temps, les ressources (ou coût), la qualité et le périmètre. Travailler avec un Atelier logiciel comme nous en bloque déjà deux.
Nos ressources sont limitées et même si elles ne l'étaient pas, 9 femmes ne font pas un enfant en un mois (Loi de Brooks).
Sauf pour des projets très spécifiques, nous ne transigeons pas sur la qualité, ce serait vous desservir.
Un choix s'offre donc à vous :
Nous livrons à l'échéance que vous avez définie, un logiciel fonctionnel, apportant de la valeur, mais au périmètre incertain.
Vous préférez ne pas fixer de délai et attendre que l'ensemble de votre logiciel soit prêt. Nous pouvons fournir un ordre de grandeur, rien de plus.
L'arbitrage entre l'envergure et les délais vous appartient complètement. Nous nous engageons à être parfaitement transparents sur les deux autres variables, à travers une tarification horaire ou journalière. Nous aidons nos clients à faire le choix le plus sécurisant pour eux.
Je n'ai jamais entrendu parler d'un projet logiciel figé, ni dans ma carrière, ni dans la littérature. Pendant le développement de votre application, la vie continue, votre métier évolue et pire : le développement de votre logiciel va nous amener inévitablement à vous poser des questions auxquelles vous n'aviez pas pensé. Il est presque sûr que ces questions vont amener une nouvelle vision de vos besoins. Pour ne rien arranger, il nous arrive également d'être force de proposition.
Je suis conscient que la culture du cycle en V est fortement ancrée dans certaines entreprises et que le management y tient. Je peux m'y adapter à condition que l'on me laisse la possibilité de travailler par itérations de mon côté. Je vous livrerai régulièrement de la valeur, comme si je travaillais en agilité. Vous êtes libre de l'intégrer ou non, ce qui vous permet une transition en douceur si vous le souhaitez.
Cette manière de travailler suppose que je sois en contact permanent avec un référent métier capable de me préciser ce que les spécifications éventuelles ne disent jamais. Je ne travaille pas sans tests automatisés, car ils sont les clauses du contrat que nous passons ensemble. Vos expert devra être en capacité de valider ces tests.
Je préfère être honnête avec mes clients. Peut-être existe-t-il des développeurs capables de tenir des engagements de qualité sans poser ces conditions. J'en suis bien incapable. Je sais d'expérience que je suis incapable de développer de bons logiciels si ces deux critères ne sont pas remplis.
TLDR;
Pour les missions d'audit, toujours sur site. Pour les formations, les parties magistrales peuvent être à distance, pas les TP/exercices/Katas, sauf le suivi des projets en fin de cours. Pour le développement, de préférence à l'Atelier, sauf si une phase du projet requiert ma présence sur site.
L'Atelier est d'abord le lieu où l'artisan travaille. Je passe la majorité de mon temps à façonner des logiciels dans un environnement que j'ai adapté à l'exercice efficient de mon art. Demanderait-on à un menuisier de produire une huisserie sur site, au cul du camion ? Le développement de logiciels requiert également un environnement de travail adapté à la main de l'artisan.
Toutefois, lorsque le projet le requiert (recueil du besoin, livraison, etc.), je me déplace dans vos locaux, sur le chantier ou dans tout autre lieu où ma présence serait nécessaire. L'échange humain direct, chargé d'implicite et de non-verbal, charrie une densité d'information qu'aucune technologie ne peut retranscrire. Ma vision de l'audit est intégrale : ne lire que le code c'est passer à côté du contexte qui l'a produit. Cela revient souvent à reproduire indéfiniment les mêmes erreurs. Tous mes audits se font en partie là où travaillent vos équipes.
En dehors des cas sus-mentionnés, il peut m'arriver d'accepter des missions "sur site", de courte ou moyenne durée. Je tiens à ce qu'elles restent l'exception. L'environnement de bureau ne m'a jamais paru propice à l'exercice de mon métier, qui nécessite d'alterner des phases sociales avec de longs silences studieux. Les explications sont ici.
Sur la formation
Quelles prestations proposez-vous aux établissements de formation ?🔗
En plus des cours, les établissements avec lesquels je travaille me sollicitent pour des prestations annexes, comme les jurys ou les suivis de mémoires professionnels. Je ne suis pas fermé à l'idée de travailler avec des établissements dans lesquels je n'enseigne pas, à condition que le sujet traité corresponde à mon coeur de métier. Les apprenants bénéficient de ma veille scientifique le temps de leur mémoire et au-delà.
Ma pédagogie est très pratique, à travers la répétition de katas et la réalisation de projets en situation semi-professionnelle.
En plus de croire fermement que la pratique encadrée par un maître est la seule école du développeur, j'ai été traumatisé par ces diaporamas de 1200 slides, subis encore aujourd'hui par trop d'étudiants. Je ne veux pas être ce genre de formateur.
Je ne rejette pas la forme magistrale pour autant, mais celle-ci vient plutôt introduire une matière, préciser des notions ou encore enseigner des connaissances théoriques nécessaires à l'exercice suivant.
Je pense qu'un bon enseignement est constitué de 20% de théorie, 20% de démonstration et 60% de pratique.
Partout en France, tant que l'établissement défraie. Habituellement, je me rends sur le lieu de mes cours pour des durées d'une semaine à un mois.
J'ai déjà enseigné à Arras, Toulouse, Montpellier, Lyon, Nantes et Bordeaux ainsi.
Nous demandons simplement aux reponsables pédagogiques de regrouper au maximum les cours.
We can work in english as developers. We cannot teach nor audit yet as it requires extended understanding of implicit meanings.
We plan to spend some months in an anglo-saxon country to improve our english.
