Développeur et non-développeur n’est pas la bonne division ; ce qui compte avec le no-code c’est de savoir ce que l’on fait

Chers lecteurs marketing : restez avec moi ici. J’ai raison. Promesse.

J’ai commencé à programmer quand j’étais enfant, en écrivant des jeux multijoueurs pour connexion commutée. systèmes de tableaux d’affichage (BBS) — un précurseur du Web et des médias sociaux tels que nous les connaissons aujourd’hui. C’était à la fin des années 80, au début des années 90, et j’écrivais principalement dans une langue appelée Cavec quelques composants occasionnels hautes performances écrits en 8086 Langage d’assemblage.

Pour ceux d’entre vous qui ne sont pas des développeurs de logiciels – ou pour vous les jeunes développeurs qui ont grandi en pensant à Java était un langage de bas niveau — voici à quoi ressemble le code assembleur :

Vous épelez littéralement des instructions individuelles au processeur, déplacez des octets de la mémoire vers des registres, exécutez des opérations mathématiques simples sur ceux-ci et créez un flux de programme avec des portes logiques primitives de AND, OR, XOR.

Tout en reconnaissant la puissance cosmique de cette fondation de bas niveau sur laquelle tous les logiciels ont été construits, permettez-moi simplement de dire que l’écriture d’Assembly était nulle.

En tant que game designer, j’avais en tête des scénarios, de nouveaux mondes que je voulais créer, des interactions entre les joueurs que je voulais permettre. Traduire cela en code, en particulier les parties des instructions d’assemblage énigmatiques, revenait à plonger des hauteurs du mont Everest jusqu’aux profondeurs de la fosse des Mariannes. La tête pourrait exploser.

Quelques éléments dont je me souviens de cette expérience :

Premièrement : cela prenait énormément de temps. Un ensemble de mécanismes de jeu que je pourrais vous expliquer en 30 secondes – un de mes jeux permettant aux joueurs de mélanger différentes potions pour en créer de nouvelles, plus complexes, passant à des élixirs magiques toujours plus puissants – prendrait 30 jours pour se développer. Oui, le codage a permis de créer ces choses. Mais le coût élevé du codage constituait également un obstacle à la concrétisation de nombreuses autres idées.

Deuxièmement : c’était très sujet aux erreurs. Même les grands programmeurs se retrouvent avec des « bugs » dans leurs logiciels. J’étais, au mieux, un homme moyen. J’ai donc eu beaucoup de bugs dans mon code. Les découvrir a été difficile. Dans des programmes plus complexes, comme un jeu multijoueur, même être capable de tester toutes les façons possibles dont quelque chose pourrait mal tourner était une tâche exponentielle. Les réparer pourrait être encore plus difficile.

Relativement peu de mes bugs étaient des défauts dans la conception du jeu. Presque toutes étaient des erreurs accidentelles commises lors du processus de codage, traduisant un flux conceptuel parfaitement valide en milliers de lignes de code, où une simple faute de frappe pouvait tout faire planter. Le code est fragilemes amis.

D’ailleurs, il n’y a pas Lac Wobégon. La moitié de tous les programmeurs sont en dessous de la moyenne. Et ceux qui sont en dessous de la moyenne peuvent écrire un code tellement infesté de bugs que si le programme était votre maison, votre sympathique professionnel Orkin vous recommanderait de l’essence et une allumette.

Troisièmement : il était facile de perdre l’intrigue. La tête baissée dans le code, essayant d’implémenter une fonction récursive folle, jonglant avec des pointeurs vers un fouillis de différentes structures de données, je ne pensais plus au jeu ni à ses joueurs. J’ai été consumé par pointeurs sauvages, pointeurs suspendus, fuite de mémoire, impact de la modification du pointeur de base et accès aux adresses hors de portée les erreurs.

Cependant, malgré tout cela aboutissant à un code médiocre, les jeux eux-mêmes sont devenus très populaires pour leur époque, joués par plus d’un million d’utilisateurs sur les BBS du monde entier. Leur succès fut malgré mes défauts en tant que développeur de logiciels.

La morale de cette promenade nostalgique dans le passé : le code et la programmation ont toujours été un moyen imparfait pour parvenir à une fin.

Retour vers le futur pour vraiment MOVE CX, DX

Avance rapide de quelques décennies jusqu’à aujourd’hui – et la prolifération des outils sans code.

Le débat continue de faire rage sur la sagesse ou la folie de laisser les employés non-informaticiens créer des flux de travail, des applications, des agents ou des expériences client composées avec des plateformes sans code. Chaque fois que je publie un article sur l’utilisation croissante du no-code dans le marketing et le martech, comme celui de la semaine dernière Chaque marketeur est un analyste de données et un ingénieur… illusion ou destin ? — J’entends des gens qui insistent sur le fait que les non-développeurs n’ont pas les compétences nécessaires pour construire quelque chose de bon.

Avec tout le respect que je vous dois, ils ont tort.

Tout d’abord, le code n’est pas intrinsèquement meilleur que le no-code. L’histoire de la programmation a été une marche constante vers des niveaux d’abstraction plus élevés. Nous avons commencé avec des cartes perforées. Je suis tombé sur le langage Assembly, qui, je le répète, était aussi amusant à travailler qu’une mine de sel. Puis des langages de niveau supérieur comme C, C++ et Java. Et puis des langages encore plus performants (et plus sûrs), comme Python, avec plus de 350 000 packages que vous pouvez utiliser pour « composer » des programmes étonnants en une fraction du temps qu’il fallait dans les mines de sel.

Le no-code est la prochaine étape dans cette progression de l’abstraction, où plus que jamais, il s’agit de comprendre ce que vous voulez construire et votre capacité à le décrire – visuellement ou avec une interface en langage naturel (merci, gen AI). Ne pas avoir à vous soucier de choses telles que des pointeurs non initialisés et des défauts de segment constitue une amélioration considérable pour la qualité de vie d’un constructeur. La plupart des outils non codés disposent d’excellents garde-fous, contrairement au code brut.

« Mais même en no-code, c’est une question de logique et de pensée programmatique », répondront les critiques. Et ils ont raison – à propos de cette première partie. Mais ensuite ils terminent cette phrase en ajoutant : «Et seuls les développeurs de logiciels et les professionnels de l’informatique possèdent ces compétences.« 

Désolé, mais c’est incorrect dans les deux sens.

D’une part – en repensant à mes jours bâclés de code – être un développeur de logiciels ne vous rend pas automatiquement doué en logique ou en pensée programmatique. Ne vous offensez pas, mais il existe de nombreux développeurs inférieurs à la moyenne dont la compréhension de la logique et de la pensée programmatique n’est pas excellente. Ce n’est pas parce que vous faites appel à un « développeur de logiciels » pour créer quelque chose que cela fonctionnera comme prévu (ou pas du tout).

De l’autre, ne pas être développeur de logiciels cela ne veut pas dire que la logique et la pensée programmatique vous échappent intrinsèquement. Finance. Opérations. Légal. De nombreux professionnels possèdent de grandes compétences en logique et en pensée programmatique, même si un écran rempli de Javascript serait pour eux aussi indéchiffrable que le sanskrit. (Quid pro quo : demandez à votre programmeur Python moyen d’essayer de comprendre les mécanismes d’une feuille de calcul de budgétisation Excel auprès d’un analyste financier principal dans une entreprise publique. Demandez-lui ensuite de me l’expliquer.)

Opérations de marketing, opérations de vente, opérations de révision – ces disciplines prospérer sur la logique et la pensée programmatique. Cartes de parcours client, orchestrées par des outils d’automatisation du marketing, transmises à des séquences de vente algorithmiques pilotées par des déclencheurs et des actions conditionnelles… ce sont des « programmes » logiciels astucieux qui sont conçus par des experts dans leur domaine.

« Des experts dans leur domaine » sont la clé. Un bon professionnel des opérations marketing peut créer d’excellents flux de travail programmatiques avec un outil d’automatisation sans code, avant tout parce que ils comprennent profondément le contexte de ce qu’ils construisent. Ce n’est pas seulement qu’ils sont compétents dans la conception d’un déroulement logique d’un programme. Ils savent ce que signifient réellement ces déclencheurs et ces actions. Ils savent quel résultat ils tentent d’atteindre. Ils savent ce qui peut mal tourner avec le processus métier.

À une époque où les outils sans code – et même les « copilotes » de la génération IA pour la construction avec code – facilitent de plus en plus le travail de mise en œuvre technique de création d’une application ou d’une automatisation, la vraie valeur est de savoir quelle application ou quelle automatisation créer. Que faut-il faire ? Pourquoi? Comment (du point de vue du processus, pas au niveau technique du code brut) ?

L’expertise du domaine est ici la clé de voûte.

Les outils sans code permettent aux personnes possédant une expertise approfondie du domaine – et des compétences parfaitement fines en matière de logique et de réflexion programmatique, dont le seul « défaut » est qu’ils n’ont pas appris à coder en Python pythonique – de transformer rapidement et efficacement leurs connaissances en de meilleures opérations numériques et expériences.

Les outils sans code peuvent-ils également permettre à des personnes qui n’ont aucune idée de ce qu’elles font de créer des flux de travail et des automatisations vraiment merdiques ? Malheureusement, oui. Mais ce n’est pas que différent du chaos qu’un développeur de logiciels qui ne sait pas ce qu’il fait peut semer.

Ne confondez pas savoir coder et savoir ce que vous faites.

Le plus grand avantage de l’ère du no-code est la séparation de ces deux éléments.

Et maintenant, un mot données utiles de notre sponsor…

Alors que les coûts de publication de ce blog et de cette newsletter augmentent, j’expérimente des moyens d’accepter des parrainages qui ne soient pas ininterrompus et qui, je l’espère, vous seront utiles, cher lecteur. Une idée que j’essaie aujourd’hui est de mettre en évidence un rapport d’un sponsor qui, je pense, contient des données et des informations qui pourraient vous être utiles. Je ne le partagerai que si je pense vraiment que c’est bien, mais je suis payé pour l’inclure. Vous pouvez m’aider à soutenir mes écrits en les consultant.

Notre premier sponsor est MoEngage, qui vient de publier son Rapport sur l’état du marketing cross-canal 2024. Étude menée auprès de plus de 700 spécialistes du marketing B2C, elle comprend des données utiles sur les canaux et priorités marketing, les défis et les solutions. Par exemple, cette répartition des canaux que les spécialistes du marketing B2C utilisent actuellement :

Quels sont les principaux défis auxquels les spécialistes du marketing sont confrontés lorsqu’ils adoptent de nouvelles technologies pour le marketing cross-canal ? Eh bien, la réponse n°2 est — surprise, surprise — « problèmes d’intégration avec les technologies existantes » (27,6 %). Les autres défis du Top 5 ? Eh bien, tu devras obtenir une copie de leur rapport découvrir.