Du développement logiciel à l’entrepreneuriat

On connaît le portrait du fondateur venu de la technique : brillant lorsqu’il s’agit de construire, mal à l’aise lorsqu’il faut vendre, et contraint de désapprendre ses réflexes d’ingénieur avant de pouvoir diriger une entreprise. Ce portrait n’est pas entièrement faux. Il néglige pourtant l’essentiel. Les disciplines qui font un bon développeur – décomposer un problème, éprouver ses hypothèses, préférer les faits à l’enthousiasme – ne sont pas des obstacles à l’entrepreneuriat. Bien prolongées, elles en sont l’un des socles les plus sûrs.

Le parcours d’Ahmad Athamneh permet d’éprouver cette idée. Il commence par un diplôme en technologies de l’information, se poursuit par des années de développement et de conseil technique, passe par un MBA à Oxford et par le marketing numérique au sein d’une plateforme mondiale, pour aboutir à un ensemble de projets qui touchent à la diffusion en direct, à l’événementiel, à l’intelligence artificielle et aux actifs numériques. Aucune de ces étapes n’est exceptionnelle en soi. Ce qui est instructif, c’est la manière dont chacune modifie le sens des précédentes.

Ce que le développement logiciel enseigne

Le développement logiciel enseigne une forme particulière d’honnêteté. Un programme fonctionne ou ne fonctionne pas ; un système tient la charge ou cède sous les yeux de ses utilisateurs. Le développeur apprend tôt que l’assurance ne prouve rien, et que l’essentiel du travail se joue dans l’écart entre une conception séduisante et un produit qui marche.

Trois réflexes issus de cette discipline se transposent particulièrement bien au monde des affaires. Le premier est la décomposition : l’instinct de découper un objectif vaste et flou en problèmes plus petits, que l’on peut comprendre et résoudre. Une entreprise est, en ce sens, un système – de clients, d’incitations, d’opérations, de technologie et de capital – et ses difficultés cèdent à la même analyse patiente.

Le deuxième est l’itération. Un ingénieur s’attend rarement à réussir du premier coup : il construit, teste, observe, puis affine. Le fondateur qui transpose ce réflexe à la stratégie s’éprend moins facilement de son propre plan et perçoit plus vite le moment où le marché lui dit autre chose.

Le troisième est l’attention aux modes de défaillance. Un bon ingénieur ne se demande pas seulement comment un système fonctionne, mais comment il casse. Dans l’entreprise, cela se traduit par une vision lucide du risque – réglementaire, opérationnel, réputationnel – souvent absente des formes plus optimistes d’entrepreneuriat.

Ce que la technique n’enseigne pas

Si ces réflexes constituent un héritage, ils ne forment pas une éducation complète. La formation technique tend à considérer le besoin comme une donnée. L’entrepreneuriat exige au contraire de le découvrir : comprendre ce dont les gens ont réellement besoin, ce pour quoi ils sont prêts à payer, et ce qui les fera revenir.

C’est là que l’expérience acquise hors de l’ingénierie devient décisive. Le marketing numérique, par exemple, est d’abord un travail de compréhension des publics : comment ils découvrent un contenu, ce qui retient leur attention, comment la culture et la langue façonnent ce qui les touche. Pour un esprit formé aux systèmes, c’est une leçon sur toutes les variables qui ne figurent dans aucun cahier des charges.

Une formation au management ajoute une autre couche : le langage du capital, de l’organisation et de la stratégie. Un MBA ne fait de personne un entrepreneur, mais il fournit des cadres pour des questions que l’on pose rarement aux ingénieurs – comment évaluer une opportunité, comment structurer une organisation, comment penser la concurrence à l’horizon de plusieurs années plutôt qu’au rythme des mises en production.

L’apprentissage du conseil

Entre l’ingénierie pure et la création d’entreprise se trouve une étape trop souvent sous-estimée : le conseil. Le consultant technique est appelé dans les organisations aux moments qui comptent – lorsqu’un système doit monter en charge, qu’un service doit être modernisé ou qu’une plateforme doit être construite sous le regard de tous. Il voit de nombreuses organisations de l’intérieur, souvent en peu de temps, et apprend à lire le contexte institutionnel avec autant d’attention que l’architecture technique.

Contribuer à des plateformes de services numériques à grande échelle offre en particulier des enseignements difficiles à acquérir autrement. La fiabilité y devient une obligation morale plus qu’un indicateur. La coordination entre de nombreuses équipes y devient le défi central. Et le consultant y apprend que la meilleure réponse technique n’est pas toujours celle qu’une institution peut adopter – une leçon que tout fondateur finit par rencontrer face à ses partenaires, à ses régulateurs ou à ses grands clients.

Le passage à la création

Vient souvent un moment où ceux qui ont ce type de parcours doivent choisir : continuer à construire des systèmes appartenant à d’autres et à les conseiller, ou lancer leur propre projet. La décision tient rarement à la compétence technique. Elle tient à l’envie d’assumer une autre forme de responsabilité – celle de la masse salariale, de la stratégie, et de décisions dont on ne peut renvoyer les conséquences à personne.

La création d’une plateforme de diffusion en direct, comme YouLive fondée par Ahmad en 2019, montre comment les étapes précédentes se combinent. Une plateforme de direct est exigeante sur le plan technique, sensible sur le plan culturel et délicate sur le plan économique. Elle demande une ingénierie capable de tenir en temps réel, une compréhension fine des comportements du public et des créateurs, et un modèle économique qui rémunère équitablement chacun. Aucune des expériences antérieures n’y suffirait seule ; ensemble, elles forment une base solide.

D’une entreprise à un ensemble de projets

Les étapes suivantes d’un tel parcours s’élargissent plus souvent qu’elles ne s’approfondissent. Un parc d’exposition, deux projets en activité dans les technologies de santé et d’éducation, une plateforme d’échange en développement : cela peut ressembler à une dispersion. Vus avec les yeux de l’ingénieur, ces projets partagent pourtant une même structure – chacun est un système qui met en relation des acteurs qui ont besoin de se trouver, de se faire confiance et d’échanger.

Cette continuité compte, car elle détermine la manière d’évaluer chaque projet. Les questions restent les mêmes : le problème est-il réel ? Le système peut-il être construit au niveau d’exigence requis ? Qui porte le risque, et est-ce juste ? Sommes-nous précis sur ce qui existe aujourd’hui et sur ce qui relève encore du projet ?

Cinq réflexes à emporter

Pour le développeur ou l’ingénieur qui envisage un parcours comparable, voici ce qui compte le plus :

• Considérez vos réflexes techniques comme un atout, non comme un handicap. Décomposition, itération et respect des faits sont rares sur des marchés qui récompensent les belles histoires. Servez-vous-en.
• Allez chercher délibérément ce que l’ingénierie ne vous apprend pas. Le marketing, la vente, les opérations ou le conseil enseignent les variables humaines et institutionnelles qui décident de l’utilité d’une technologie.
• Ne négligez pas l’apprentissage du conseil. Voir de nombreuses organisations de l’intérieur est une formation accélérée à la manière dont les décisions se prennent réellement.
• Soyez précis sur le statut de vos projets. La crédibilité d’un fondateur repose sur une distinction nette entre ce qui fonctionne, ce qui est en développement et ce qui n’est encore qu’une idée.
• Choisissez des problèmes où votre combinaison de compétences est rare. La position la plus solide pour un fondateur technique se trouve souvent à la croisée de disciplines qui se rencontrent peu.

Une rigueur qui s’élargit

On décrit parfois le passage du développement logiciel à l’entrepreneuriat comme un abandon de l’ingénierie. Il serait plus juste de parler d’un élargissement : des systèmes de code aux systèmes faits de personnes, d’incitations et d’institutions. Le fondateur qui réussit cette transition ne renonce pas à la rigueur du développeur. Il l’applique à des problèmes plus vastes et plus lourds de conséquences, et il l’enrichit d’une compréhension des marchés et des personnes que le code, à lui seul, n’aurait jamais pu lui donner.