Ce que j'ai compris du développement, en observant les programmeurs de l'extérieur pendant des années

Des années passées dans les affaires, surtout dans un domaine éloigné de l'IT, m'ont appris une chose importante : entre le « je veux » et le « comment faire » dans le monde de la programmation, il y a un véritable abîme. Je ne suis pas programmeur de formation – mon parcours a commencé par le sport, la peinture, puis l'économie et l'aménagement paysager. Néanmoins, depuis le début des années 90, lorsque je gérais le fonds de pension non étatique « Alkar » et donnais des tâches aux programmeurs pour la comptabilité de gestion, jusqu'à la création de formspace.design à 61 ans, j'ai constamment été confronté au développement. Et voici ce que j'en ai compris, en observant de l'extérieur.

Le fossé entre « je veux » et « comment faire »

La première et peut-être la plus importante chose que j'ai réalisée est la différence fondamentale de mentalité. L'entrepreneur, le praticien, pense en termes de tâches et de solutions pour le client : « Nous avons besoin que le client puisse choisir des plantes selon certains critères », « J'ai besoin d'un rapport sur la marge des projets ». Le programmeur, lui, pense en termes de code, d'algorithmes, de structures de données, d'efficacité et de scalabilité. Il ne voit pas l'utilisateur final comme je le vois. Pour lui, la tâche « choisir des plantes selon des critères » se décompose en base de données, filtres, requêtes, éléments d'interface, etc. Et souvent, dans cette traduction, l'essence se perd. Par exemple, je peux dire : « Il faut un CRM pour une entreprise d'aménagement paysager », sous-entendant la gestion de 20 projets simultanés, avec 20 à 30 paramètres pour chaque plante et un cycle de travail complexe. Le programmeur, lui, peut commencer par un CRM de base qui convient à n'importe quelle entreprise, sans approfondir les spécificités.

L'importance d'un cahier des charges clair et pourquoi il est toujours « insuffisant »

J'ai rédigé des cahiers des charges de nombreuses fois – d'abord pour les systèmes de comptabilité de gestion chez « Alkar », puis pour l'automatisation des processus chez « Dom i Sad ». Et à chaque fois, il me semblait avoir tout détaillé. Mais après la première itération, je réalisais qu'il manquait quelque chose. Les programmeurs ne lisent pas entre les lignes, ils ne devinent pas le contexte. Si je n'ai pas précisé que lors du calcul du coût d'un pavage de 50 m² avec trois types de dalles, il fallait tenir compte de 5 % de déchets et de prix de pose différents pour chaque type, le calcul sera une simple multiplication de la surface par le prix. Ce n'est pas leur faute, c'est ma responsabilité en tant que client. J'ai compris que pourquoi la dette technique en entreprise commence par un mauvais briefing est une conséquence directe d'un cahier des charges incomplet, même s'il est volumineux. Chaque incertitude est une erreur ou un retard potentiel.

La pensée du programmeur : non pas « quoi », mais « comment »

Les programmeurs sont des ingénieurs qui construisent des ponts avec du code. Ils se soucient de la solidité de la structure, de son efficacité, de sa vitesse. Moi, en tant que propriétaire d'entreprise, je me soucie davantage que le pont mène là où il faut et que les gens puissent y passer. Cela ne signifie pas que la qualité du code n'est pas importante, mais les priorités divergent souvent. Un programmeur peut passer des heures à optimiser une requête qui s'exécute en 0,01 seconde pour qu'elle s'exécute en 0,005 seconde, alors que pour l'entreprise, il est plus important qu'une nouvelle fonctionnalité génératrice de revenus apparaisse. Cette différence de focus est l'une des raisons clés pour lesquelles la différence entre un produit de programmeurs et un produit de praticien est si grande. Ils voient le code, je vois la solution au problème du client.

La dette technique et ses racines dans la communication

La dette technique n'est pas simplement un « mauvais code ». C'est, avant tout, le résultat de compromis acceptés au stade du développement en raison d'exigences floues ou d'une recherche de résultats rapides sans planification adéquate. Je me souviens d'un cas où j'avais besoin d'implémenter d'urgence un nouveau type de calcul pour déterminer la marge des services. Le programmeur a fait un « bricolage rapide » qui fonctionnait, mais était étroitement lié à un service spécifique. Six mois plus tard, lorsque de nouveaux services sont apparus et qu'il a fallu adapter le calcul, ce « bricolage » est devenu un énorme problème, nécessitant une refonte complète. Ce qui aurait pris quelques jours au départ avec une bonne planification s'est transformé en semaines de travail et des milliers de dollars de coûts. C'est un exemple typique de la façon dont le refus ou l'incapacité de plonger profondément dans la logique métier au début conduit à des problèmes à long terme.

Comment j'ai appris à parler leur langage (ou du moins à le comprendre)

Au fil des ans, j'ai compris que la seule façon de combler ce fossé était de me rapprocher moi-même de la logique de développement. Cela ne signifie pas que je suis devenu un programmeur professionnel, mais j'ai commencé à étudier les bases, à comprendre l'architecture des systèmes, à saisir les principes de fonctionnement des bases de données. Et avec l'avènement de l'IA, à 61 ans, j'ai obtenu un outil qui m'a permis non seulement de donner des tâches, mais de les formuler, de communiquer directement avec le « code », en vérifiant mes hypothèses et même en créant des prototypes. Cela m'a donné une liberté incroyable et la possibilité de construire formspace.design sans avoir de personnel de programmeurs. C'est un chemin accessible à quiconque est prêt à se plonger dans le domaine et à faire preuve de discipline.

Quand le produit est nécessaire « ici et maintenant », et non « quand il sera finalisé »

Une entreprise ne peut pas attendre des années un produit idéal. Il faut un MVP (Minimum Viable Product) – un produit minimal viable qui résout le problème principal du client, même s'il n'est pas parfait. Les programmeurs visent souvent la perfection, une architecture impeccable, l'absence de bugs. C'est louable, mais dans le monde réel, cela signifie des opportunités manquées et des clients perdus. Mon expérience m'a appris à valoriser la rapidité et l'itération. Il vaut mieux lancer un produit avec 80 % des fonctionnalités réellement nécessaires et le peaufiner rapidement en fonction des retours, plutôt que de perfectionner 100 % des fonctionnalités qui pourraient s'avérer inutiles.

Comment mon expérience s'est reflétée dans formspace.design

Toutes ces années d'observation et de travail avec les programmeurs, toutes mes « douleurs » et mes « révélations » ont servi de base à formspace.design. Je l'ai créé comme un outil qui aplanit au maximum ces angles vifs. J'ai cherché à le rendre intuitif pour les paysagistes et les propriétaires de terrains, afin qu'ils puissent concrétiser leurs idées sans se plonger dans les arcanes techniques. L'absence de personnel de programmeurs et l'utilisation de l'IA dans le développement m'ont permis de créer un produit qui reflète les besoins réels du marché, et pas seulement les capacités techniques. C'est un produit que j'aurais moi-même voulu avoir dans ma pratique.

Comment planifier un aménagement paysager dans formspace.design

Imaginez que vous souhaitez créer sur un terrain de 15 ares une zone de détente avec une pergola et un petit bassin. formspace.design est conçu comme un pont entre votre idée et sa réalisation, en évitant les explications complexes avec des spécialistes techniques. D'abord, je téléchargerais une photo aérienne ou dessinerais le contour du terrain dans le module 1.0 « Plan du terrain ». Cela permet d'obtenir rapidement une base de travail.

Ensuite, en utilisant les modules de zonage (1.1 « Zones »), je définirais l'emplacement de la zone de détente, de l'aire de jeux pour enfants et du potager, en tenant compte de l'orientation et de la pente. Dans le module 2.1 « Concept IA », on peut obtenir plusieurs options de design, simplement en décrivant ses souhaits. Par exemple, « style moderne, minimalisme, prédominance de conifères ». L'IA proposera des idées qui pourront ensuite être détaillées, en ajoutant des objets (1.2 « Objets ») — la même pergola, des bancs, des luminaires. Et le module 3.1 « Design par photo » permettra de voir comment les éléments choisis rendront sur une photo réelle de votre terrain. Cela permet d'avoir une vue d'ensemble et d'éviter de nombreuses erreurs avant même le début des travaux, sans recourir à des services de concepteurs coûteux ou à de longues explications avec les exécutants.

Questions fréquentes

Puis-je me passer de programmeurs si j'ai l'IA ?

L'IA simplifie considérablement le processus de développement et permet aux non-programmeurs de créer des produits complexes, comme je l'ai fait avec formspace.design. Cependant, il est encore difficile de se passer complètement de la compréhension des principes de base de la programmation ou d'une aide extérieure pour les étapes complexes. L'IA est un assistant puissant, mais pas un substitut aux connaissances approfondies.

Quelle est la principale différence d'approche entre le business et l'IT ?

Le business est axé sur le résultat final, sur la résolution du problème du client et la génération de profits. Les spécialistes IT se concentrent sur le processus de création, sur la qualité du code, son efficacité et sa scalabilité. La principale différence réside dans les priorités : le business valorise la rapidité et la fonctionnalité, l'IT la fiabilité et la pureté architecturale.

Comment éviter les retouches et refontes interminables ?

La clé du succès est un cahier des charges aussi détaillé et univoque que possible, ainsi qu'une approche itérative avec des retours fréquents. Divisez le projet en petites étapes vérifiables (MVP) et testez chaque fonctionnalité immédiatement après sa mise en œuvre. Cela permet de corriger le cap avant que les erreurs ne deviennent critiques.

Faut-il étudier les bases du codage pour une meilleure communication ?

Je pense que oui. Il n'est pas nécessaire de devenir un programmeur professionnel, mais la compréhension des concepts de base (logique, structures de données, principes de fonctionnement des API) améliorera considérablement votre capacité à donner des tâches et à comprendre les réponses des développeurs. C'est comme apprendre quelques phrases dans une langue étrangère pour mieux s'orienter dans un nouveau pays.

Pourquoi les programmeurs ne comprennent-ils souvent pas des choses « évidentes » pour le business ?

Ce qui semble « évident » pour le business est souvent basé sur des années d'expérience dans un créneau spécifique et des hypothèses implicites. Un programmeur, n'ayant pas cette expérience, ne peut pas considérer ces hypothèses comme « évidentes ». Il travaille avec ce qui est explicitement écrit. Votre tâche est de rendre l'implicite explicite, en détaillant au maximum le contexte et la logique métier.

Comment choisir le bon développeur pour son projet ?

Recherchez des développeurs qui manifestent un intérêt pour votre domaine d'activité et posent beaucoup de questions sur les processus métier. Ce n'est pas seulement leur stack technique qui est important, mais aussi leur capacité d'empathie, leur désir de comprendre pourquoi ils créent le produit. Vérifiez impérativement leur portfolio et leurs références, de préférence avec des projets similaires au vôtre.

Mon produit est trop niche, faut-il l'automatiser ?

Oui, les produits de niche bénéficient souvent le plus de l'automatisation, car les solutions standard leur conviennent rarement parfaitement. La création d'un outil spécialisé, même s'il est petit, peut donner un énorme avantage concurrentiel et augmenter considérablement l'efficacité. C'est précisément sur cette expérience de niche que formspace.design a été construit.

Qu'est-ce que la « dette technique » du point de vue du business ?

Du point de vue du business, la dette technique est un coût caché qui surviendra à l'avenir en raison de décisions prises maintenant pour économiser du temps ou des ressources. C'est comme contracter un prêt : vous obtenez quelque chose maintenant, mais vous payez des intérêts plus tard. Ces « intérêts » se manifestent par un ralentissement du développement de nouvelles fonctionnalités, des erreurs fréquentes, une complexité de mise à l'échelle et un coût élevé de maintenance du produit.

Mon chemin vers formspace.design a été long, plein d'erreurs et de découvertes dans la communication avec le monde du développement. Mais chacune de ces compréhensions m'a rendu plus fort et m'a aidé à créer un produit qui, je l'espère, sera utile à des milliers de personnes. L'essentiel est de ne pas avoir peur de se plonger dans ce qui semble complexe, et de toujours se souvenir pour qui et pourquoi vous créez votre produit. C'est cela, la véritable expérience.

Articles connexes

• Lire la suite