Mon parcours vers formspace.design : quand les développeurs ne me comprenaient pas

Au cours de ma longue carrière d'entrepreneur, j'ai souvent été confronté au même problème : comment expliquer à un développeur ce dont j'avais besoin et obtenir exactement cela, plutôt que quelque chose de similaire mais absolument inutile pour mon entreprise. Ce sont des années d'essais et d'erreurs, de frustrations et de ressources gaspillées qui m'ont finalement conduit à la création de formspace.design. J'ai compris que la meilleure façon d'obtenir l'outil idéal était de le construire moi-même, en m'appuyant sur mon expérience unique.

Le début du chemin : comment j'ai compris le besoin d'automatisation

Mon histoire d'interaction avec les développeurs a commencé dès les années 90, lorsque j'étais directeur adjoint chez NPF « Alkar ». Ma tâche, entre autres, était de définir les objectifs pour les programmeurs en matière de comptabilité de gestion. Déjà à l'époque, je ressentais à quel point il était difficile de traduire des processus métier intuitifs en un langage de code strict. Ce qui semblait être une tâche simple – automatiser les rapports ou la gestion des stocks – se transformait en de longues explications qui aboutissaient rarement au résultat escompté.

Plus tard, en dirigeant l'entreprise « Dom i Sad » de 2000 à 2022, j'ai continué à chercher des moyens d'automatisation. Nous avons essayé de mettre en œuvre divers systèmes CRM, mais chacun d'eux nécessitait une adaptation, et les explications de mes besoins aux développeurs externes se heurtaient encore et encore à un mur d'incompréhension. J'ai décrit ces difficultés en détail dans l'article « Des années sans comptabilité de gestion normale chez "Dom i Sad" : les conséquences ». C'était un cercle vicieux : je passais du temps à expliquer, de l'argent sur des ajustements, et au final, j'obtenais un produit qui ne résolvait que partiellement les problèmes, ou même en créait de nouveaux.

Le problème de la traduction : langage métier vs. langage technique

Le problème principal réside dans la différence de mentalité. L'entrepreneur pense en termes de résultats, d'efficacité, d'expérience client. Ma vision d'un projet paysager est une image holistique où chaque détail a son importance, où il y a de la place pour la créativité et la flexibilité. Le développeur, lui, pense en algorithmes, en règles claires et en opérations logiques. Pour lui, l'univoque et la prévisibilité sont essentielles. Quand je dis : « J'ai besoin que le devis soit calculé rapidement et facilement », j'entends que le système doit prendre en compte de nombreux facteurs : la surface du terrain (par exemple, 10 ou 15 ares), le type de travaux (pose de gazon en rouleau, plantation d'arbres), les matériaux choisis, la complexité du relief (coefficient de 1.0 à 1.5). Le développeur, lui, entendra « faire un bouton 'calculer le devis' » et attendra une formule détaillée pour chaque élément, sans toujours comprendre le contexte.

Erreurs typiques dans la définition des tâches

Au fil des ans, j'ai identifié plusieurs erreurs typiques que je commettais moi-même et que je voyais chez d'autres :

1. Détail insuffisant. Des phrases générales comme « rendre pratique » ou « rendre beau » ne contiennent aucune information pour le développeur. Il a besoin de scénarios d'utilisation concrets.
2. Changement des exigences en cours de route. Le monde des affaires est dynamique, et les changements sont inévitables. Mais chaque modification de ce type, sans une fixation claire et une révision du cahier des charges, entraîne le chaos et des coûts supplémentaires. Parfois, nous pouvions passer 2 à 3 mois à former les employés à l'utilisation d'un nouveau CRM, pour finalement nous rendre compte qu'il ne convenait pas en raison des exigences constamment changeantes.
3. Absence de scénarios d'utilisation clairs. Je ne pouvais pas toujours imaginer toutes les situations possibles dans lesquelles le programme serait utilisé. L'absence de « user stories » faisait que le système ne fonctionnait pas dans des conditions réelles.
4. S'attendre à ce que le développeur « devine » lui-même. C'est probablement l'erreur la plus courante. Le développeur n'est pas un expert de votre secteur. Il ne doit pas « deviner » les nuances implicites de l'aménagement paysager ou de la gestion de projet. Ma tâche était de formuler clairement ces nuances.
5. Se concentrer sur le « comment faire » plutôt que sur le « ce qui doit être obtenu ». Parfois, je me plongeais trop dans les détails techniques, essayant de suggérer comment implémenter telle ou telle fonction, au lieu de décrire clairement le résultat final souhaité et la valeur commerciale.

Comment apprendre à parler aux développeurs

Mon expérience m'a appris plusieurs règles importantes :

• Rédigez un cahier des charges aussi détaillé que possible. Il ne doit pas s'agir d'une simple liste de fonctions, mais d'une description des processus métier, des scénarios utilisateur, des exemples de données d'entrée et de sortie attendues. Plus il y a de détails, moins il y a de place pour l'interprétation.
• Utilisez des prototypes et des maquettes. Même un croquis d'interface dessiné à la main, des captures d'écran ou de simples prototypes dans Figma peuvent en dire plus que mille mots. Ils permettent de visualiser le futur produit et de détecter les malentendus dès les premières étapes.
• Découpez la tâche en petites étapes mesurables. Au lieu d'une grande tâche « créer un CRM », il est préférable d'en définir 10 à 20 petites : « implémenter l'ajout d'un client », « créer un filtre par date », « configurer l'envoi de notifications ». Cela permet de contrôler le processus et d'ajuster le cap.
• Concentrez-vous sur les processus métier et le résultat attendu. Commencez toujours par la question : « Quel problème utilisateur ou métier cela résout-il ? » et « Quel résultat concret voulons-nous obtenir ? ».
• Donnez des exemples concrets. Si une fonction doit calculer quelque chose, donnez des exemples avec des chiffres. Si elle doit traiter des données, montrez à quoi ressemblent ces données.

Conséquences d'une communication inefficace

Une communication inefficace avec les développeurs a toujours eu des conséquences fâcheuses. Premièrement, c'est une perte de temps et d'argent. Les projets s'éternisaient, les budgets explosaient, et nous obtenions toujours « pas ce qu'il fallait ». Deuxièmement, cela provoquait de la frustration et une baisse de motivation au sein de l'équipe. Lorsque les employés voient que les efforts d'automatisation ne portent pas leurs fruits, leur enthousiasme diminue. Je me souviens de cas où, après plusieurs mois de mise en œuvre et de formation, nous n'avons pas pu lancer le système à pleine capacité, car il s'est avéré trop lourd ou ne tenait pas compte des spécificités de nos processus, par exemple, les particularités de la comptabilité des matériaux pour les travaux paysagers ou la planification de l'irrigation pour un terrain de 20 ares.

Désespoir et naissance de l'idée formspace.design

À un moment donné, j'ai compris : pour obtenir un outil qui corresponde parfaitement à mes besoins, je devais le créer moi-même. Pour moi, un homme de 61 ans à l'époque et qui n'avait jamais été programmeur professionnel, cela semblait fou. Mais des années de frustration et le désir de créer quelque chose de vraiment utile pour l'industrie du paysage l'ont emporté. J'ai commencé à apprendre la programmation avec l'aide de l'IA, et cela m'a ouvert de toutes nouvelles possibilités. J'ai décrit ce parcours dans l'article « Comment moi, ancien expert en marketing, je conçois formspace.design ». C'est ainsi qu'est née l'idée de formspace.design — une plateforme créée par un spécialiste du paysage pour des spécialistes du paysage, où l'intuition et la créativité ne se heurtent pas aux barrières du langage technique.

Comment planifier avec formspace.design

formspace.design est une réponse directe au problème de communication entre le designer et le développeur. C'est un outil qui vous permet, en tant que spécialiste de l'aménagement paysager, de concrétiser directement vos idées, sans avoir à les traduire en langage technique. Je l'ai construit de manière à ce qu'il soit intuitif et aussi proche que possible des étapes réelles de travail sur un projet.

Imaginez que vous deviez planifier un terrain de 18 ares. Vous commencez par le Module 1.0 « Plan du terrain », où vous définissez facilement les limites, placez les structures existantes et les réseaux. Ensuite, vous passez au Module 1.1 « Zones » pour délimiter intuitivement les zones fonctionnelles : par exemple, une zone barbecue de 4x5 mètres, une aire de jeux pour enfants de 6x6 mètres, un potager, une zone de détente. Vous voyez tout cela immédiatement, visuellement, sans avoir à expliquer vos intentions à qui que ce soit.

Si vous avez une idée générale mais manquez d'idées concrètes, utilisez le Module 2.1 « Concept IA ». Vous pouvez télécharger une photo du terrain ou même simplement un moodboard, décrire vos préférences – par exemple, « un jardin moderne et minimaliste avec un accent sur les plantes persistantes et un plan d'eau » – et l'intelligence artificielle générera plusieurs options de concepts. Pour une visualisation plus détaillée d'éléments spécifiques, le Module 3.1 « Design par photo » vous permet de télécharger une photo d'un lieu existant et d'« essayer » différents éléments de design : changer le pavé, ajouter des arbustes, modifier la couleur de la façade de la maison. Tout cela se déroule en temps réel, et vous voyez immédiatement le résultat, sans les longues correspondances et révisions inévitables lorsque vous travaillez avec des prestataires externes. Cela vous permet de vous concentrer sur la créativité, et non sur les détails techniques de la définition des tâches.

Questions fréquentes

Pourquoi est-il si difficile d'expliquer ses processus métier à un développeur ?

Les processus métier sont souvent informels, contiennent de nombreuses exceptions et dépendent du facteur humain ou de décisions intuitives. Un développeur, lui, pense de manière strictement logique, exigeant des algorithmes et des règles clairs pour chaque situation. Cette différence fondamentale d'approche et l'absence de contexte commun créent la principale barrière de communication.

Quelles sont les principales erreurs des entrepreneurs lors de la commande de logiciels ?

Le plus souvent, cela se manifeste par l'absence d'un cahier des charges détaillé, des critères d'acceptation imprécis et des changements constants d'exigences pendant le développement sans documentation appropriée. Beaucoup s'attendent également à ce que le développeur devine les nuances implicites de leur entreprise, ce qui entraîne des malentendus importants et la nécessité de refontes coûteuses.

Comment éviter la situation « j'ai reçu autre chose » ?

Commencez par le prototypage : même un simple croquis ou une maquette aidera à visualiser le futur produit et à identifier les divergences. Divisez la tâche en petites étapes itératives avec des vérifications régulières des résultats. Il est important de se concentrer sur ce que le système doit faire et la valeur qu'il doit apporter, plutôt que sur comment cela sera techniquement réalisé.

Faut-il avoir un bagage technique pour donner des tâches aux développeurs ?

Il n'est pas nécessaire d'être développeur, mais comprendre les bases de la logique de fonctionnement des programmes et savoir penser de manière systémique simplifie considérablement le processus. Développez vos compétences en structuration de l'information et en formulation des exigences de manière aussi claire que possible, en utilisant des exemples concrets et des scénarios d'utilisation pour minimiser l'ambiguïté.

Que faire si le projet ne se déroule pas comme prévu ?

Arrêtez-vous immédiatement et menez une rétrospective avec l'équipe pour déterminer clairement ce qui n'a pas fonctionné et pourquoi. Revoyez le cahier des charges, et si possible, divisez le travail restant en tâches plus petites et gérables. Il est parfois préférable d'arrêter le projet et de repartir de zéro ou de changer de prestataire plutôt que de continuer à investir dans une direction vouée à l'échec.

Pourquoi formspace.design résout-il ce problème pour les paysagistes ?

formspace.design a été créé par moi, une personne de l'industrie du paysage, qui a personnellement rencontré ce problème. J'ai construit un outil intuitivement compréhensible pour les designers, leur permettant de concrétiser directement leurs idées sans avoir à les traduire en langage technique pour les développeurs. Cela élimine l'intermédiaire et minimise les risques de malentendus, garantissant la précision et la rapidité de la réalisation de la vision.

Quelles étapes concrètes m'ont aidé à passer des « explications » à la « création » ?

La clé a été de réaliser que personne ne comprendrait ma vision unique aussi bien que moi-même. J'ai commencé à étudier activement les possibilités des technologies modernes, en particulier l'IA, pour automatiser le développement. Cela m'a permis, sans être un programmeur professionnel, de commencer à créer formspace.design, en m'appuyant sur ma vaste expérience en aménagement paysager et en affaires. Ce fut une transition des tentatives de faire comprendre aux autres à l'incarnation autonome de mon idée.

Mon parcours vers formspace.design est l'histoire de la façon dont des années d'expérience et la confrontation à des problèmes récurrents peuvent devenir un puissant stimulant pour la création de quelque chose de nouveau. Si vous aussi, vous êtes fatigué des malentendus et souhaitez vous concentrer sur la créativité plutôt que sur les explications, essayez formspace.design. Je suis sûr que vous apprécierez la différence quand l'outil parle votre langue.