Votre logiciel sur mesure, utilisable en un mois, pour un budget mensuel fixe. Voici qui porte cette promesse.

De 2012 à 2014, j’ai préparé un BTS en domotique, en alternance comme technicien en portes automatiques. Je l’ai obtenu de justesse. Je comptais ensuite faire un bachelor pour concevoir des applications d’objets connectés. Mes résultats m’ont découragé, et j’y ai renoncé. Puis j’ai travaillé dans les systèmes de sécurité électronique.

En 2016, j’ai décidé de relancer mon projet de devenir développeur. L’idée ne m’avait jamais quitté, et pour des raisons personnelles, il fallait de toute façon que je le fasse. Petit à petit, je m’y suis remis, en parallèle de mon travail. Un développeur m’a expliqué deux ou trois choses et m’a un peu aidé. En 2017, un organisme de formation m’a démarché et m’a vendu une formation de neuf mois. J’aurais dû me méfier : une bonne école n’a pas besoin d’aller chercher ses élèves. Mais je voulais à tout prix devenir développeur, et ma situation était fragile. J’étais naïf. Du matin au soir, de 8 h à 18 h, on nous faisait regarder des vidéos, puis en rédiger des comptes rendus. Ensuite, entre élèves, nous nous testions les uns les autres avec des QCM pour vérifier que nous avions compris. C’est ainsi qu’on nous apprenait la programmation, soi-disant. Dans ma classe, la plupart des élèves étaient dans une situation précaire. Beaucoup étaient étrangers, et on leur présentait cette formation comme leur espoir de rester en France et d’avoir enfin un travail intéressant. Au bout de trois mois, la commerciale d’une ESN liée à cet organisme est venue repérer des élèves à présenter à ses clients. Elle m’a choisi. Pour être présenté, je devais afficher sur mon CV cinq ans d’expérience et un master. J’ai refusé. Avec ce CV, on m’aurait confié un projet que je n’étais pas capable de mener à bien, et ce sont l’équipe et le client qui en auraient payé le prix. La réponse a été : « Sébastien, tu ne respectes pas les conditions de vente de l’établissement. » On m’a renvoyé de la formation, en me demandant, « par déontologie », après tout ce que l’établissement avait « fait pour moi », de ne pas parler de ces pratiques à l’extérieur. Cet établissement agissait comme une secte, et ses conditions de vente relevaient du mensonge et de la manipulation. Très vite, dès mes premiers mois dans cette industrie, j’ai vu dans quoi je mettais les pieds : un monde de charlatans. Je n’ai pas eu de premier poste de développeur. Dès mes premiers pas vers ce métier, je ne voulais pas transiger sur mes principes. En attendant, j’ai préféré me tourner vers un autre métier, le support informatique, plutôt que de me faire passer pour quelqu’un que je n’étais pas. Et j’ai appris seul à côté. Autour de moi, les gens du métier parlaient de projets qui avaient mal tourné. Je me disais que, moi, je m’en sortirais. Je m’intéressais déjà à l’agilité, une façon de construire un logiciel par petites étapes, en l’ajustant au fil des retours. Certains textes que je lisais me parlaient, sans que je les comprenne vraiment. Je n’avais pas encore connu ces problèmes.

D’octobre à décembre 2018, j’ai suivi une formation accélérée en développement web. Elle m’a donné les bases et m’a rendu autonome pour apprendre. J’en suis sorti certifié en développement et en intégration web. En janvier 2019, j’ai créé ma micro-entreprise et trouvé mes premiers clients. J’ai commencé en sous-traitance pour un développeur des Pays-Bas qui avait quinze ans d’expérience. Sur son projet, les déploiements et les tests étaient déjà automatisés, une hygiène que très peu d’applications web avaient à l’époque.

En août 2019, j’ai repris mes études en bachelor, un bac+3 en développement d’applications. Dans ce bachelor, les étudiants étaient livrés à eux-mêmes. Quand je posais une question, les professeurs répondaient : « Débrouille-toi, fais tes recherches. » Je me demandais ce que je faisais là. Alors je me suis débrouillé : j’ai acheté des cours et monté mes propres projets. Les rares étudiants qui ont réussi ont fait de même.

À l’examen final, j’ai demandé au jury si je devais poursuivre en master. Au vu de mes projets, il m’a conseillé d’aller directement sur le marché du travail : je pourrais toujours reprendre mes études ensuite. Il a ajouté : « D’habitude, on ne le dit pas, mais partez tranquille, vous avez votre diplôme. Ce conseil, on ne l’aurait pas donné à vos camarades. » Quand j’ai annoncé à la responsable des études que je m’arrêtais là, elle m’a dit : « On forme si bien nos élèves en bachelor qu’ils n’ont pas besoin d’aller en master. » Je n’ai rien répondu, pour ne pas lui casser le moral. En réalité, j’avais dû apprendre seul, et aller chercher des sujets dont, déjà à l’époque, les gens de mon niveau ne se souciaient pas forcément.

Cela tient à mon parcours et à ma façon de raisonner, qui ont changé en 2017, lorsque j’ai suivi un séminaire religieux qui préparait à enseigner. On ne peut pas enseigner ce qu’on ne comprend pas, ni ce dont on n’est pas convaincu : on le ferait sans enthousiasme, sans zèle. On y apprenait donc à faire ses recherches, à remonter aux origines pour comprendre, et à se fonder sur des preuves plutôt que sur de simples croyances. En BTS, je n’avais pas encore cette façon d’étudier. Il me manquait des bases, en mathématiques par exemple, et je n’avais ni le temps ni le soutien pour y revenir. En bachelor, je l’avais acquise. Quand je ne comprends pas quelque chose, je ne l’accepte pas : je pose des questions jusqu’à en avoir fait le tour. S’il le faut, je reviens aux notions les plus élémentaires. Sans cela, on bâtit un château de cartes, et l’on travaille machinalement. Et si l’on me confie une responsabilité, je veux l’assumer entièrement. Je ne veux pas que mes erreurs retombent sur les autres.

En 2021, le projet sur lequel je travaillais accumulait du retard. Mon premier réflexe a été de rattraper le temps perdu à force d’heures supplémentaires, de week-ends et de nuits trop courtes. Je ne sortais plus. Rien n’y faisait : l’écart ne se réduisait pas, et ma santé en pâtissait. J’ai compris que je jouais à un jeu auquel il est impossible de gagner. Il fallait faire autrement, par respect pour le budget du client et pour notre santé. Toute l’équipe, pas seulement moi, voulait rester sur un sujet qui l’intéressait, en vivre et être fière du résultat. J’ai pris les devants et je me suis investi, moi aussi, dans la gestion du projet, alors que ce n’était pas mon poste. Personne n’avait intérêt à ce que le projet échoue, ni le client, ni l’équipe, dont le travail en dépendait.

Pour tenir le budget et les délais, notre équipe a dû faire un choix : cesser de développer des fonctionnalités au seul motif que le cahier des charges les prévoyait. Pour honorer la promesse faite aux utilisateurs, il n’était pas nécessaire de tout livrer dans la première version. Nous avons repoussé celles qui restaient à faire, consolidé celles déjà développées qui étaient indispensables, et abandonné celles qui étaient commencées mais pas essentielles à ce stade. Surtout, nous nous sommes concentrés sur ce qui comptait vraiment. Nous avons respecté la troisième échéance, la première où j’avais pu m’occuper moi-même de la gestion du projet, et livré une application utilisable. J’ai compris qu’en partant de l’essentiel dès le début, l’application aurait pu être utilisable en un mois, le reste venant ensuite, sans sacrifier la qualité. Je ne savais pas encore ce qu’était vraiment l’agilité. Mais j’ai vu ce qu’apporte une gestion de projet qui s’adapte.

Je voulais monter en compétence sur les tests automatisés : savoir où en mettre, et comment bien tester une application. J’ai cherché des gens qui maîtrisent le sujet et je suis tombé sur une conférence de Dave Farley, l’inventeur du pipeline de déploiement, qu’on appelle souvent pipeline CI/CD. Avec Jez Humble, il a défini la livraison continue, dont ces tests ne sont qu’une partie. Ce qu’il explique est simple et applicable.

Restait la question du budget. Je savais qu’on ne peut pas le fixer à partir d’estimations, ni tenir un calendrier avec elles. Mais je ne savais pas comment faire autrement. Je connaissais le Manifeste agile depuis mes débuts, et j’en partageais une valeur : partir de ce que les utilisateurs doivent pouvoir faire, et ne construire que ce qui y sert.

Je savais que ce que je voyais se répéter n’était pas une impression. Ce que je voulais savoir, c’est si c’était documenté, chiffré. J’ai fait des recherches et je suis tombé sur des études indiquant que 0,5 % des projets de grande envergure, tous secteurs confondus, respectent le budget, le calendrier et la valeur attendue (Bent Flyvbjerg, How Big Things Get Done, 2023, 16 000 projets). Tenir les trois à la fois relève de la chance : dans le métier, on appelle cela le triangle de fer, et il y a toujours un côté qui casse. Les autres projets dépassent leur budget, ou le tiennent en renonçant à une partie de ce qui était prévu, comme nous l’avions fait. Une autre étude m’a aussi marqué : elle montre que seulement 1/3 des idées testées chez Microsoft améliorent l’indicateur visé (Ronny Kohavi et coauteurs, Online Experimentation at Microsoft, 2009). Le problème venait de la façon de mener les projets, et cela peut changer. Depuis, je veux être au contact des utilisateurs pour comprendre leurs objectifs, sans que personne entre nous ne transforme ce qu’ils disent. Un intermédiaire peut faciliter le recueil des besoins, pour que les développeurs ne passent pas tout leur temps en échanges, mais pas empêcher les uns et les autres de se parler. Une fois une fonctionnalité en ligne, je vérifie que son objectif est bien atteint. Sinon, on risque de livrer des choses dont personne ne se sert.

En 2023, dans un grand groupe, j’ai rejoint l’équipe d’un projet qui a duré deux ans, avec deux millions d’euros investis. Plusieurs équipes travaillaient sur le même logiciel, chacune sur sa propre copie du code. Personne ne demandait d’intégrer le travail au fur et à mesure. Au bout de quatre mois environ, il a fallu réunir le travail de toutes les équipes : tous les bugs sont ressortis d’un coup, avec les conflits entre les copies et les arbitrages sur le code à garder. Après des mois d’attente, chacun dans son équipe, nous avons enchaîné deux semaines d’heures supplémentaires et de stress. Il aurait suffi d’intégrer le travail en continu, petit à petit. L’intégration à peine terminée, un responsable que nous ne voyions jamais est venu nous annoncer que le projet était annulé : le marché n’était pas intéressé par ce que nous faisions. Rien n’avait pourtant jamais été mis en production : le logiciel n’avait jamais été confronté à ses utilisateurs. Des collègues m’ont alors dit, contents : « On s’améliore : avant, il nous fallait six ans pour arriver à cette conclusion, maintenant il n’en faut plus que deux. » Un développeur de mon équipe m’a aussi confié : « Cela fait cinq ans que je suis ici, et aucune des choses sur lesquelles j’ai travaillé n’a fini en production. » Là, je me suis dit : non, je ne reste pas.

Plus tard, au cours d’une autre mission, une rétrospective réunissait l’équipe chaque semaine, comme le veut Scrum, pour chercher comment améliorer les processus de l’organisation. On me demandait mes propositions, et la réponse était : « Cela fait cinq ans qu’on travaille comme ça, et on ne changera pas. » Là, je réalise qu’il y a quelque chose d’hypocrite. Je ne comprends pas ce que je fais là. On balaye mes remarques, et finalement on m’écarte, après m’avoir fait comprendre que je ne rentrais pas dans les processus internes de l’équipe. Aujourd’hui, lorsque l’on est indépendant en régie, on est traité comme un salarié, et l’on se retrouve en situation de fausse indépendance. C’est après cet épisode que j’ai décidé de prendre le taureau par les cornes et de monter en compétence sur ce qui me manquait encore pour comprendre comment l’agilité s’applique au développement d’un logiciel sur mesure, afin de prendre enfin mes projets de bout en bout.

Et il était temps : j’avais déjà obtenu des résultats en appliquant cette approche. En 2024, sur un projet, l’application comptait 600 utilisateurs au bout de trois mois de développement. J’avais aidé le fondateur à comprendre que ce qui compte, ce ne sont pas les fonctionnalités qu’il a en tête, mais d’aller interroger ses utilisateurs, de ne développer que ce qu’ils demandent, et de livrer les nouvelles fonctionnalités au fur et à mesure, en flux continu. La même année, sur un autre projet, parce que nous avions tous la même approche, nous avons proposé l’application à 30 bêta-testeurs au bout de six mois de développement.

Depuis 2019, je regardais les conférences de Frédéric Leguédois sur l’agilité, en vidéo sur YouTube. C’est une référence sur le sujet, en France au moins. En 2026 seulement, j’ai eu la chance de suivre sa formation « Un retour à l’essence de l’Agilité », où il m’a formé directement à la gestion de projet adaptative : fixer le coût et la qualité, et laisser le client piloter le périmètre. J’avais enfin ma réponse à la question du budget : c’est ce qu’une entreprise est prête à investir pour développer et faire évoluer son logiciel, mis en balance avec ce que lui coûte le problème tant qu’il n’est pas résolu. Je pratiquais déjà une partie de ces méthodes. Cette formation m’en a donné le cadre complet. C’est sur cette base que j’ai créé l’offre de DEVEDANOS.

J’ai donc choisi un autre standard que celui des estimations et des plannings figés : l’approche adaptative en livraison continue. Je voudrais que davantage d’entreprises en profitent, pour que leurs projets aboutissent, que leur argent serve, que leurs équipes travaillent sans urgence permanente, que les développeurs ne sacrifient plus leur santé, et que nous tirions tous satisfaction et fierté d’un travail bien fait.

Cela passe par la qualité du logiciel, sécurité comprise. Les estimations n’étant jamais tenues, ce modèle oblige à renégocier le budget ou à livrer moins, souvent les deux. Quand une estimation semble tenue, c’est de la chance. Même avec de la marge, les délais ne se tiennent qu’en sacrifiant la qualité et la sécurité, sans que cela se voie. Or une fonctionnalité livrée ainsi ne se modifie plus : elle reste en l’état, et quand trop de fonctionnalités sont dans ce cas, il faut refaire le logiciel. Cela coûte cher. La qualité est la première touchée : la capacité du logiciel à rester facile à faire évoluer, et sa sécurité. Il ne reste alors ni le budget pour faire appel à des experts, ni le temps pour que les développeurs, qui ne sont pas des chercheurs en sécurité, la traitent dans leur périmètre. Le standard que DEVEDANOS applique à chaque projet ne fait aucun compromis sur la qualité ni sur la sécurité : cela fait partie de notre chaîne de livraison, pour chaque modification de votre logiciel.

Imaginez un chantier mené comme un projet logiciel. Le plombier pose ses tuyaux, puis le maçon referme le mur. Arrive l’électricien : « Ah non, il faut que je passe aussi mes câbles là-dedans. » Le maçon recasse le mur, et il faut peut-être faire revenir le plombier. Dans le logiciel, c’est souvent ainsi. On l’a banalisé, et personne n’ouvre les yeux sur l’absurdité de la situation. Dans ce métier, beaucoup sont pris dans un engrenage où il faut se taire et ne pas faire de vagues, pour ne pas se faire renvoyer. Par instinct de survie, puisque tout leur revenu en dépend, ils se taisent. Il ne fait pas bon être différent et poser des questions. J’ai décidé de ne plus remettre les pieds dans de telles organisations, pour ma santé mentale et pour ne pas prendre de mauvaises habitudes d’ingénierie.

C’est par passion du travail bien fait que je ne prends à présent que des projets de bout en bout. Car je désire que chaque euro, chaque effort, chaque heure investie dans mon travail produise un résultat le plus tôt possible, durable, et dont mes clients et moi sommes fiers.

Une fonctionnalité part en production une fois recettée et approuvée.

Un budget fixe pour le développement de votre application et son ajustement en continu à l’évolution de votre activité, aussi longtemps que vous le souhaitez, facturé par mensualité pour le travail réalisé du mois. Vous décidez du périmètre, à mesure que la réalité bouge.

Il repose sur deux choses. L’agilité, la vraie, celle d’une approche adaptative : adapter le produit aux besoins de ses utilisateurs et rester centré sur eux. Et la livraison continue (Dave Farley, Jez Humble) : un code de qualité, facile à changer. L’un ne va pas sans l’autre. Les meilleures idées ne servent à rien si le code est difficile à changer : c’est un pilote de course au volant d’un tuk-tuk. Et un code excellent ne sert à rien si l’on ne comprend pas ses utilisateurs : c’est une Ferrari confiée à quelqu’un qui n’a jamais conduit qu’un tuk-tuk. Notre page Approche en détaille la mécanique.