Ça me trotte dans le crâne depuis environ un mois, mais j’ai eu du mal à mettre des mots dessus. C’est coton parce que la psychologie de l’ingénierie logicielle est compliquée, et les raisons pour lesquelles les entreprises continuent d’acheter des logiciels sont complexes. Ça n’a jamais vraiment été une question de spécificités de produit. Il y a autre chose.
Si j’étais manager et qu’un membre de mon équipe me disait : « Regardez combien on pourrait économiser avec cette appli en vibe coding qu’on a faite pour remplacer le Fournisseur X », ça me rendrait nerveuse.
Et je pense que ça me rendrait nerveuse pour les mêmes raisons qui auraient rendu un manager nerveux face à l’open source il y a 20 ans.
Est-ce que c’est éprouvé ?
Peut-être ?
Est-ce qu’il y a un support ?
Non ?
Ok... combien ça va me coûter quand un truc va foirer royalement ?
Aucune idée, hein.
C’est non.
L’autre truc que les gens n’arrêtent pas de dire, c’est : « C’est tellement pas cher et facile à faire ! ». Tout ce que je peux en déduire, c’est que ces gens n’ont jamais essayé de faire de la « rétro-ingénierie » (on utilise toujours le mauvais terme, la nomenclature correcte pour ce qui se passe est le « reversement de contrat ») sur des applis de ce genre, sinon ils ne diraient pas ça.
Si c’est plus gros qu’une boîte à pain, ou que ça a plus de deux ans, ça va demander des efforts, du temps, de la réingénierie et une connaissance directe de l’application elle-même.
Ces trucs-là sont toujours lents et fastidieux, parce que ce n’est pas un problème de parallélisme, et balancer plus d’agents sur un problème que ni vous ni eux ne comprenez ne va pas accélérer les choses.
D’un autre côté, le calcul change pas mal si vous avez l’impression d’être dans une relation abusive avec un fournisseur et qu’il n’y a pas beaucoup d’options.
À votre avis, pourquoi ils s’en sont pris à Adobe en premier ?
La suite plus tard.
Je vous aime tous.