Le dev est le seul outil qui n'a pas d'API
<p class="lead">Le dev est le seul outil qui n'a pas d'API.</p>
Un dev ouvre Jira pour savoir quoi faire.
Il retrouve le bon repository parmi les dix qu'il a ouverts cette semaine.
Il ouvre son IDE et tire la branche.
Il note deux ou trois choses dans un onglet Notepad, ce qu'il ne faut pas oublier, ce qu'il a compris du ticket.
Il ouvre VSCode avec une IA pour écrire le code.
Il lance Docker pour faire tourner l'app en local.
Il ouvre le navigateur pour vérifier que ça tourne.
Il lance les tests dans un autre onglet.
Il pousse, ouvre la MR sur GitHub.
Il regarde Jenkins pour voir si la CI passe.
Il repasse sur Jira pour mettre à jour le ticket.
Onze gestes. Six outils. Douze onglets. Et aucun ne sait ce que font les autres.
Chaque outil est bon. L'ensemble ne l'est pas.
Aucun de ces outils n'est mauvais.
Jira fait très bien ce qu'il fait. GitHub aussi. Docker aussi. Jenkins aussi. Git aussi. VSCode aussi.
Le problème n'est pas la qualité des outils. Le problème est qu'ils ne se parlent pas.
Le ticket sait qu'il y a une branche. La branche sait dans quel dépôt elle vit. Le dépôt sait qu'il y a une MR. La MR sait qu'il y a une CI. La CI sait qu'il y a un test qui a échoué.
Mais personne ne relie tout ça. Sauf le dev, dans sa tête.
Le ticket est dans Jira. La branche est dans git. Le dépôt est dans l'IDE. La MR est sur GitHub. La CI est dans Jenkins. Le test qui casse est dans un onglet de terminal. Le contexte du ticket est dans un onglet Notepad.
Six endroits. Un seul cerveau pour faire le lien.
Ce que personne ne mesure
Ce temps n'apparaît nulle part.
Ni dans un daily. Ni dans un burndown. Ni dans une estimation. Ni dans une revue de sprint.
Il existe pourtant. Il est même la partie la plus fatigante de la journée, celle qui casse le plus l'attention, celle qu'on ne peut pas facturer, celle qu'on ne peut pas expliquer à un manager qui demande pourquoi une tâche de deux heures en a pris quatre.
Ce n'est pas du temps perdu. C'est du temps de liaison. Et personne ne le compte.
Le code n'a plus de valeur en soi
Pendant vingt ans, la valeur d'un dev, c'était sa capacité à écrire du code. À connaître la syntaxe, les patterns, les frameworks, les bibliothèques. À résoudre des problèmes en assemblant des lignes.
Ce n'est plus vrai.
Aujourd'hui, c'est l'IA qui écrit le code. Sur les directives du dev. Le dev décrit ce qu'il veut, l'IA produit, le dev relit, corrige, valide.
Le code lui-même est devenu une commodité. Il est produit en quelques secondes, dans n'importe quelle langue, dans n'importe quel framework, à un niveau de qualité tout à fait correct.
Ce qui a de la valeur, c'est ce qui reste autour. Comprendre le besoin. Décider de l'architecture. Arbitrer entre deux approches. Relier le ticket à la branche, la branche au dépôt, le dépôt à la CI, la CI au test qui casse. Garder le fil du travail dans un environnement qui n'a jamais été conçu pour ça.
Un dev ne devrait plus perdre son temps à faire le lien entre ses outils. Il devrait écrire du code avec l'IA, et garder son attention pour ce qui compte.
Ce que voudrait dire relier
Relier, ce n'est pas remplacer. Personne n'a envie de changer Jira pour autre chose, ni GitHub, ni Docker, ni Jenkins. Les équipes ont mis des années à les configurer, à former les gens, à écrire des process autour. Ces outils fonctionnent, ils sont installés, ils sont connus.
Relier, c'est faire en sorte qu'ils se parlent enfin.
Savoir qu'un ticket Jira a une clé, et que cette clé est dans une branche.
Savoir que cette branche vit dans un dépôt précis, et que le dev devrait l'ouvrir dans son IDE.
Savoir que cette branche a une MR, et que cette MR a une CI.
Savoir que cette CI a un test qui a échoué, et que ce test concerne un fichier précis.
Savoir que ce fichier a été modifié dans un commit, et que ce commit est lié à une session d'IA.
Savoir que cette session a produit un rapport, et que ce rapport mentionne le même ticket.
Rien de tout ça n'est magique. Ce sont juste des liens.
Mais aujourd'hui, aucun outil ne les tient. Alors c'est le dev qui les tient, dans sa tête, onglet après onglet, toute la journée.
Ce que fait Mergerie
Mergerie ne remplace aucun de ces outils.
Il ne demande pas de quitter Jira, ni GitHub, ni Docker, ni Jenkins. Il ne demande pas de changer d'IDE, ni de CLI d'IA, ni de forge.
Il se branche sur ce qui existe déjà, et il relie.
Il sait qu'un ticket Jira a une clé, et que cette clé doit se retrouver dans une branche. Il sait qu'une branche vit dans un dépôt précis, et quel dépôt ouvrir. Il sait qu'une branche a une MR, que cette MR a une CI, que cette CI a un test qui a échoué.
Il sait aussi que deux ou trois choses méritent d'être notées, et il leur donne un endroit où vivre, lié à l'objet concerné, au lieu d'un onglet Notepad qui disparaîtra au prochain redémarrage.
Il ne produit pas de code à la place du dev. Il ne prend pas de décision à la place du dev. Il ne merge pas à la place du dev.
Il fait le lien. C'est tout. Mais c'est exactement ce que personne ne fait aujourd'hui.
Le dev est le seul outil qui n'a pas d'API.
Mergerie est son API.