Marketing vs Développement : une guerre éternelle et un amas de dette technique

Pourquoi les développeurs adorent les demandes absurdes du marketing (et la dette technique qui va avec)

Ah, le marketing. Cette merveilleuse discipline qui sait exactement ce dont le produit a besoin, sans jamais avoir à écrire une seule ligne de code. Et fort heureusement, les marketeux seraient sûrement moins enthousiastes à chaque dinguerie qui pop dans leurs cerveaux comme des notifications WhatsApp sur leur dernier iPhone.

Nous, développeurs, sommes reconnaissants à chaque réunion quand vous débarquez avec une liste interminable de “petites” fonctionnalités à implémenter. Parce qu’évidemment, les « petites » modifications, ça prend quoi ? 5 minutes, max ?

La magie des “petites” modifications et la dette technique qui en découle

Il est toujours émouvant de voir avec quelle candeur l’équipe marketing annonce ses demandes :

• “On pourrait avoir un chatbot intelligent propulsé par IA pour guider l’utilisateur ? Mais genre, pour demain ?”
• “Pourquoi ne pas permettre aux utilisateurs de personnaliser l’interface en drag-and-drop avec des options illimitées ?”
• “Si le dashboard du site vitrine du boucher pouvait être totalement personnalisé, il pourrait avoir une analyse plus fine de ses KPI et augmenter son CA ?”

Bien sûr, ces demandes sont basées sur des “analyses de marché ultra-précises” (traduction : une discussion informelle avec un client qui a dit que ce serait “chouette”). Et qui sommes-nous, simples développeurs, pour remettre en question cette étude scientifique de haut niveau ?

Car si, par malheur, avec notre esprit cartésien, nous venons interroger la pertinence de vos idées, nous sommes catalogués comme réfractaires aux changements : “De toute façon, vous les développeurs, dès qu’il s’agit de retoucher à votre code, c’est toujours compliqué, il faut toujours réfléchir 23 jours avant d’implémenter une nouvelle fonctionnalité…”

“On teste et on voit” : la recette parfaite pour accumuler de la dette technique

Là où le développement est une science précise (architecture, scalabilité, tests, sécurité…), le marketing préfère la philosophie du “test and learn”. Traduction : on balance n’importe quelle idée dans le backlog, on l’impose aux développeurs, et si ça ne marche pas, eh bien… on en proposera une autre tout aussi farfelue la semaine prochaine.

Bien entendu, la question du temps de développement est une notion floue dans l’univers marketing. Mais ta dinguerie là, qui n’apporte aucune valeur ajoutée au produit, elle introduit potentiellement de nouveaux bugs ou des problèmes de sécurité. En plus, ton idée moisie que j’ai dû implémenter pour hier, tu penses sérieusement que j’ai pu faire ça proprement, avec une batterie de tests automatisés ?!

Mais pour les marketeux, les “efforts de dev” sont souvent réduits à un vague “Oh, ça doit pas être si compliqué, non ?“. Faut-il essayer de les comprendre ? Après tout, leur job, c’est de vendre des rêves, pas de les coder.

 

Et la dette technique dans tout ça ?

Le pire dans tout ça, c’est que j’ai dû tordre ma clean architecture pour ajouter ta saleté en plein milieu de mon code. Car oui, chaque ligne de code doit être maîtrisée pour éviter les problèmes. Alors, quand je m’emmerde à faire un truc propre et qu’il faut tout casser pour ajouter un truc que je sais déjà inutile, ça me rend dingue. Car, contrairement à toi, j’ai pensé aux conséquences, j’ai essayé de visualiser ta demande et l’intérêt pour les utilisateurs qui, évidemment, est proche de zéro.

Et à force d’ajouter ces fonctionnalités inutiles sans prendre le temps de les concevoir correctement, on accumule ce qu’on appelle la dette technique. Oui, cette petite chose invisible pour le marketing, mais qui nous revient en pleine figure quand il faut corriger un bug critique trois mois plus tard, et qu’on se rend compte que tout est enchevêtré comme un plat de spaghettis froid.

La dette technique, c’est ce qui transforme un simple correctif en une expédition digne d’Indiana Jones dans un temple maudit. C’est ce qui fait qu’un “petit changement” peut potentiellement faire tomber tout un système. Et devine quoi ? C’est souvent causé par toutes ces “petites” idées que vous balancez sans penser à leurs conséquences.

La fin inéluctable : un ticket Jira abandonné sous une pile de dette technique

On sait tous comment ça finit. Après avoir sacrifié quelques nuits blanches, nous, développeurs, finissons par implémenter la demande absurde du marketing. Car, généralement, nous avons foi en l’humain, il y a toujours une petite chance que l’idée soit tellement subtile que nous ne soyons pas en capacité de la comprendre. Et puis, vous êtes experts de votre domaine, nous pouvons vous faire confiance…

Le lancement a lieu, et… personne n’utilise cette nouvelle fonctionnalité. L’option révolutionnaire, qui devait décupler les taux de conversion, se retrouve oubliée au fin fond du produit. Et un jour, un développeur tombera sur ce bout de code inutile, se demandera à quoi il sert, et le supprimera. Et personne ne remarquera jamais la différence. Nous aurons perdu du temps de vie, fragilisé l’application pour une idée fumeuse.

Mais ce n’est pas grave. Car déjà, une nouvelle demande « claquée au sol » arrive. Ah, le marketing… Que ferait-on sans eux ?