Questions fréquentes

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 mainiè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.

Sur la qualité
  1. Qu'appelez-vous qualité ?
  2. Ne faites-vous pas de la surqualité ?
  3. Pouvez-vous baisser vos standards pour respecter mes délais ?
Sur les technologies employées
  1. Avec quels langages travaillez-vous ?
  2. Êtes-vous compétent en Front-End ?
Sur la gestion de projet
  1. Travaillez-vous sur site ou à distance ?
  2. Je travaille en cycle en V, peut-on s'entendre ?
  3. J'ai déjà réalisé une estimation de temps, la respecterez-vous ?

Sur la qualité

Qu'appelez-vous qualité ?

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.

Ne faites-vous pas de la surqualité ?

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é.

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 :

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.

Sur les technologies employées

Avec quels langages travaillez-vous ?

Réponse courte : tout est possible.
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.

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

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.

Sur la gestion de projet

Travaillez-vous sur site ou à distance ?

L'Atelier est d'abord le lieu où l'artisan travaille. Nous passons la majorité de notre temps à façonner nos logiciels dans un environnement que nous avons adapté à l'exercice de notre art. Nous y maîtrisons notre temps et les technologies de l'information nous permettent de communiquer avec l'extérieur de manière asynchrone, afin d'éviter les interruptions. Nous avons construit à domicile les conditions optimales à l'exercice de notre art. Nous tenons à travailler au maximum dans le calme de notre atelier afin de livrer le meilleur de nous-mêmes.

Toutefois, lorsque le projet le requiert, nous effectuons le déplacement dans vos locaux, sur le chantier ou dans tout autre lieu où notre 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. Notre 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 nos audits se font en partie là où travaillent vos équipes. Il en est de même pour nos formations.

En dehors des cas sus-mentionnés, il peut nous arriver d'accepter des missions "sur site", de courte ou moyenne durée. Nous tenons à ce qu'elles restent l'exception. L'environnement de bureau ne nous a jamais paru propice à l'exercice de notre métier, qui nécessite d'alterner des phases sociales avec de longs silences studieux.

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

Dans notre courte carrière, nous n'avons jamais vu de projet figé dès l'origine qui n'ait pas bougé à la fin. 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.

Nous sommes cependant conscients que la culture du cycle en V est fortement ancrée dans certaines entreprises et que le management y tient. Nous pouvons nous adapter à condition que l'on nous laisse la possibilité de travailler par itérations de notre côté. Nous vous livrerons régulièrement de la valeur, comme pour tous nos clients. Libre à vous de l'ignorer jusqu'à la fin du cycle global.

Cette manière de travailler suppose que nous soyons en contact permanent avec un référent métier capable de nous préciser ce que les spécifications ne disent pas. Nous ne travaillons pas sans tests, ils sont les clauses du contrat que nous passons ensemble. Vos expert devra être en capacité de valider ces tests, mais également de faire remonter aux concepteurs des spécifications les changements qui s'avèrent nécessaires.

Nous préférons être honnêtes avec nous clients. Peut-être existe-t-il des développeurs capables de tenir des engagements de qualité sans poser ces conditions. Nous n'en faisons pas partie. Nous savons d'expérience que nous sommes incapables de développer ce que nous pensons être de bons logiciels si ces deux critères ne sont pas remplis.

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.

Un choix s'offre donc à vous :

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.