Comment j'ai embauché des développeurs sans savoir comment leur formuler mes besoins

Au début des années 90, lorsque je lançais tout juste mon entreprise chez NPF « Alkar », le monde des technologies de l'information était pour moi quelque chose de nouveau et de mystérieux. En tant que directeur, je voyais un énorme potentiel dans l'automatisation de la comptabilité de gestion et la création de logiciels spécialisés pour nos appareils d'entraînement isométriques. Mais il y avait un gros problème : je ne comprenais absolument pas comment « traduire » mes objectifs commerciaux dans un langage compréhensible pour les programmeurs.

L'essence du problème ne résidait pas dans l'absence d'idées, mais dans l'incapacité à les formuler clairement. Je savais ce dont j'avais besoin au final, mais je ne comprenais pas comment cela devait fonctionner de l'intérieur, quelles étapes devaient être entreprises, et quelles données étaient nécessaires en entrée et en sortie. Cela a conduit à une collaboration longue et souvent infructueuse, où nous dépensions beaucoup de temps et de ressources, pour obtenir un produit qui ne correspondait pas du tout à nos attentes.

Ma première expérience avec l'automatisation et les programmeurs

Mon activité entrepreneuriale a débuté en 1991 avec NPF « Alkar ». Nous développions des logiciels pour des méthodes d'entraînement sur des appareils isométriques, et nous tentions également d'introduire la comptabilité de gestion dans un marché commercial naissant. C'est alors que j'ai été confronté pour la première fois à la nécessité de donner des tâches aux programmeurs. J'étais plein d'enthousiasme, mais je n'avais absolument aucune expérience dans la formulation de spécifications techniques.

Il me semblait qu'il suffisait de dire : « J'ai besoin d'un programme qui calculera les revenus et les dépenses » ou « Faites en sorte que les données d'entraînement soient automatiquement sauvegardées et analysées ». Les programmeurs hochaient la tête, se retiraient dans leur « caverne » pendant plusieurs semaines, puis apportaient un produit qui nécessitait des ajustements, des refontes, et parfois ne correspondait pas du tout à mes attentes. C'était un cycle constant d'essais et d'erreurs qui m'a coûté beaucoup de nerfs et d'argent. Par exemple, l'un des modules de comptabilité, qui me semblait devoir être simple, nous a pris plusieurs mois et une somme équivalente au coût d'une petite voiture d'occasion de l'époque, et le résultat était toujours loin d'être idéal.

Erreurs typiques dans la formulation des tâches

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

1. Formulations vagues. « Rendez-le pratique », « pour que tout vole », « intuitivement compréhensible ». Ces phrases ne disent rien sur la fonctionnalité concrète.
2. Manque de détails. Je ne décrivais pas les scénarios d'utilisation : qui utiliserait le programme, quelles données seraient saisies, à quoi s'attendre en sortie dans différentes situations. Le programmeur ne pouvait pas deviner toutes les nuances de mon entreprise.
3. Changements fréquents des exigences. Pendant le développement, de nouvelles idées me venaient, et je demandais immédiatement de les implémenter. Cela déstabilisait l'équipe, allongeait les délais et augmentait les coûts.
4. Méconnaissance des contraintes techniques. Je ne réalisais pas toujours que certaines de mes demandes pouvaient être trop complexes, coûteuses ou même irréalisables avec les technologies et le budget existants.

Les leçons que j'ai tirées

Mon expérience avec « Alkar » (puis avec « Alkar-invest », où nous gérions des programmes d'investissement) m'a appris le prix d'une communication claire. J'ai compris que pour une interaction réussie avec les programmeurs, il fallait :

• Détailler la tâche au maximum. La diviser en petites étapes compréhensibles. Décrire ce qui se passe à chaque étape, quelles données sont utilisées, quel résultat est attendu.
• Utiliser le prototypage. Même un simple croquis sur papier ou dans un éditeur graphique aide à visualiser l'idée et à la valider avant de commencer le codage. C'est comme un plan avant la construction d'une maison.
• Décrire les scénarios utilisateur (User Stories). « En tant qu'utilisateur, je veux [telle fonction], afin de [obtenir tel avantage] ». Cela aide le programmeur à comprendre l'objectif et le contexte de la tâche.
• Documenter les exigences. Tout changement doit être documenté et validé pour éviter les malentendus et le travail inutile.

Du problème à la solution : FormSpace et l'IA

Toute cette expérience, cette « douleur » due à une interaction inefficace avec les développeurs, m'a conduit à une compréhension profonde de l'importance de la pensée structurée et de la visualisation. Lorsque, à 61 ans, j'ai décidé de développer FormSpace par moi-même, je savais déjà que mon outil devait aider l'utilisateur à devenir lui-même son « programmeur » en matière de planification de terrain. C'est-à-dire, exprimer son idée de la manière la plus claire et visuelle possible sans avoir besoin de la « traduire » pour quelqu'un d'autre.

J'ai commencé à coder avec l'aide de l'IA, et ce fut une véritable percée. Je peux désormais « expliquer » directement mes idées aux algorithmes, sans passer par le processus complexe d'interprétation. Cela m'a permis, à moi, une personne sans formation informatique spécifique, de créer un produit qui me manquait tant dans ma longue pratique du design paysager au sein de l'entreprise « Dom i Sad ».

Comment je planifie avec FormSpace

Mon expérience avec les programmeurs m'a appris à quel point il est important de savoir visualiser et structurer ses idées. C'est précisément ce principe qui est à la base de FormSpace. Lorsque j'ai commencé à le créer, je savais déjà que l'outil devait aider l'utilisateur à devenir lui-même son « programmeur » en matière de planification de terrain, c'est-à-dire à exprimer son idée de la manière la plus claire et visuelle possible.

Dans FormSpace, cela est réalisé grâce à une série de modules. Par exemple, dans les modules 1.x (Plan, Zones, Objets), je peux définir pas à pas toutes mes « exigences » pour le terrain : délimiter les frontières, le diviser en zones fonctionnelles (détente, potager, aire de jeux pour enfants), placer les objets clés (tonnelle, étang, chemins). Cela me permet de créer un « plan technique » détaillé de mon futur jardin, où chaque élément a sa place et sa fonction. C'est beaucoup plus efficace que de simplement décrire des idées avec des mots, et cela aide à éviter de nombreuses erreurs qui surviennent lors d'une formulation de tâche imprécise. De plus, avant de passer à des étapes plus complexes, je prête toujours attention à la logique de zonage, afin que tous les éléments du terrain soient liés entre eux fonctionnellement et esthétiquement. Pour en savoir plus sur la façon de choisir un style qui s'harmonisera avec toutes les zones, vous pouvez lire l'article Comment choisir un style de design paysager.

Ensuite, le module 2.1 « Concept IA » me permet, à partir de ces données structurées, de générer des idées et des concepts. C'est comme si j'expliquais mes exigences à un designer très intelligent qui me proposerait immédiatement plusieurs options. Et le module 3.1 « Design par photo » offre la possibilité de « superposer » ces concepts sur une photo réelle du terrain, visualisant instantanément le résultat. Cette approche minimise les risques de malentendus que j'ai rencontrés par le passé en travaillant avec des prestataires externes, et me permet de concrétiser rapidement et précisément mes idées, même s'il s'agit de l'aménagement d'un petit terrain, où chaque mètre carré compte. Les nuances de la planification de tels espaces sont abordées dans notre article Particularités de l'aménagement d'un petit terrain.

Questions fréquentes

Peut-on se passer d'un cahier des charges précis si le programmeur est très expérimenté ?

Même le programmeur le plus expérimenté ne peut pas lire dans les pensées. Un cahier des charges précis (ou son équivalent, par exemple, des user stories détaillées et des prototypes) est la base d'un projet réussi. L'expérience du programmeur l'aidera à mieux interpréter vos idées et à proposer des solutions optimales, mais sans données initiales, il travaillera à l'aveugle, ce qui entraînera inévitablement des refontes et une perte de temps.

Que faire si les exigences changent constamment pendant le travail ?

C'est un processus naturel, mais il doit être géré. Il est important de convenir avec l'équipe d'une procédure de modification. Par exemple, on peut diviser le projet en petites étapes (sprints), après chacune desquelles une validation et une fixation des nouvelles exigences pour l'étape suivante ont lieu. Cela permet de contrôler le processus et d'éviter le chaos.

Que faire si je ne comprends pas les détails techniques mais que j'ai besoin d'un produit complexe ?

Dans ce cas, un analyste commercial ou un chef de projet peut vous aider en servant d'intermédiaire entre vous et l'équipe technique. Sa tâche est de traduire vos exigences commerciales en langage technique et vice versa. Il est également utile d'étudier les bases du développement pour comprendre au moins au niveau de base les possibilités et les limites des technologies.

Peut-on apprendre à formuler des tâches aux programmeurs sans formation technique ?

Absolument. Mon expérience le confirme. L'essentiel est de développer une pensée systémique, d'apprendre à détailler ses idées, à décrire les scénarios utilisateur et à visualiser le résultat souhaité. Plus vous serez capable de présenter et de décrire clairement comment le système doit fonctionner, plus il sera facile de le communiquer à n'importe quel exécutant, qu'il s'agisse d'une personne ou d'une IA.

Comment FormSpace aide-t-il à éviter les problèmes de formulation des tâches ?

FormSpace est initialement conçu comme un outil qui permet à l'utilisateur de devenir lui-même l'« architecte » de son paysage, en évitant l'étape de « traduction » de ses idées pour d'autres. Grâce à la visualisation, à la planification pas à pas et aux modules interactifs, vous formulez vous-même un « cahier des charges » clair pour votre futur jardin, ce qui réduit considérablement les risques de malentendus et d'erreurs dans la réalisation.

Mon chemin continue

L'expérience de travail avec les programmeurs m'a appris à valoriser la clarté et la systématicité. Aujourd'hui, en créant FormSpace, j'utilise toutes ces leçons. Je construis un outil qui permet à chacun de concrétiser ses idées, en contournant les barrières de la communication et des difficultés techniques. C'est un chemin accessible non seulement aux « informaticiens », mais aussi à tous ceux qui sont prêts à apprendre et à appliquer une approche structurée à leurs tâches. Essayez par vous-même comment cela fonctionne, et vous verrez comment vos idées prendront forme avec FormSpace.