Archives par mot-clé : Software

Le vrai prix du logiciel – Suite…

Et probablement pas fin 😉

Dans l’article précédent, j’explique que du logiciel, c’est rarement « un bon développeur et quelques jours ».

Un autre élément fondamental, c’est la maintenance, et surtout la gestion des évolutions du logiciel.

Quand une équipe décide d’internaliser une fonction particulière, il faut prendre en compte bien au delà du simple développement.

Un élément fondamental est la « vie » du logiciel. Dans le temps, il va falloir faire évoluer le soft.

Donc, si vous avez le choix, entre « make or buy » comme disent les américains, il faut bien mesurer toutes les conséquences de chaque option.

Attention, je ne dis pas qu’il faut forcément acheter… Un élément que vous jugez stratégique, ça serait très bien de le faire en interne.

Mais en connaissance de cause.

Le vrai prix du logiciel

Je rencontre souvent des gens qui pensent savoir ce que coute le logiciel, mais qui en fait sont, de mon point de vue, complètement à côté de la plaque.

Je parle des gens qui pensent, pensée répandue, que 1 ou 2 développeurs dégourdis peuvent monter un produit.

Le discourt, c’est : avec les technologies actuelles, les frameworks, on peut développer un produit à cout très très réduit.

C’est en général faux.

Le cas particulier, c’est celui d’un produit simple combiné à un excellent développeur. Finalement, ce cas est rare…

L’erreur vient d’une non compréhension de l’origine des coûts du logiciel.

Faire un proto, oui, ça peut se faire très rapidement et à coûts très réduits.

Faire un produit robuste, complet, qui supporte bien la charge, c’est une tout autre histoire.

Un bon produit sera suffisamment bien fait pour être évolutif. Il sera administrable. Il aura une interface bien conçue pour le client, et les cas d’erreurs seront bien traités.

Tout cela a un cout, qui peut être 10, 100 fois plus élevés que le premier proto, qui « montre » ce que pourrait être le produit, mais qui ne traite pas la charge, ni les nombreux cas d’erreurs.

Cette erreur est malheureusement porté un peu partout, et de mon point de vue, fait du tord à l’industrie du logiciel.

Les boites de soft, les vrais, sont construites par des équipes de très bons développeurs.

Attention a ne pas tomber dans l’excès inverse : dans le métier du soft, la quantité ne fait pas l’affaire.

Une petite équipe agile peut avancer bien plus vite qu’une très grosse équipe mal organisé, mal dirigé. Dans ce métier, on a des facteurs de productivité qui peuvent avoir des facteurs 100, … et même infini, car de grosses équipes peuvent ne jamais rien délivrer… J’ai ainsi entendu un retour d’expérience d’un projet informatique planté, ayant coûté 200 M€ à la boite !

Donc, pour synthétiser, je dirais :

oui l’agilité, l’extrême compétence permet de faire des miracles, des produits complexes avec de petites équipes.
non on ne bâti pas une solution complète avec un super bon développeur
non la quantité ne fait pas l’affaire.

Sur le dernier point, une anecdote : j’ai entendu un entrepreneur français très connu, expliquer très sérieusement qu’il fait du off shore pour le développement. Et d’expliquer qu’il préfère prendre 50% de développeurs en plus en les payant 70% moins cher. Raisonnement financier complètement faux dans la pratique.

Vous reprendrez bien une petite fonction ?

Vous êtes dirigeant d’un site e-commerce.

Votre obsession : faire évoluer le site pour tout un tas de raisons :

Vous avez décidé une action marketing, cela demande une petite évolution
Vous vendez un nouveau type de produit (nouvelle option par exemple)
Par rapport à un canal d’acquisition, vous avez besoin de mettre en place un tracking spécifique
Vous souhaitez changer quelques éléments dans le site : changer le look d’une page, changer la navigation, par exemple en ajoutant un popup d’ajout au panier, ….
Vous souhaitez adapter le site aux tablettes (le doigt n’interagit pas comme la souris)

Vous avez compris : Les raisons pour faire évoluer le site sont extrêmement nombreuses et on en rajoute en permanence.

Pour booster votre business, vous devez en permanence faire évoluer le site, rapidement.

Alors, vous faites une liste de course, que vous soumettez à l’équipe technique, interne ou externe.

Votre site est « tout neuf ». A ce stade, normalement, ça se passe bien. l’équipe fait les développements, avec des délais qui vous semblent raisonnables.

Bon, si dès le début les délais sont long, il faut se poser des questions : le site a-t-il bien été développé ? Bien développé, ça veut dire en particulier que le code source permet de faire évoluer le site avec des délais raisonnable justement.

Ah, ce sujet est compliqué à traiter : si votre demande d’évolution n’est pas codée rapidement, c’est pas forcément que le site est mal fait, c’est êut être que la demande qui vous paraît simple ne l’est peut être pas tant que ça… ça demande de s’assoir avec l’équipe technique, et de discuter, pour comprendre d’ou viennent les éléments de complexités.

Bon je reprends : au début, normalement donc, les « petites » évolutions sont plutôt rapide.

Ensuite, les choses se gâtent : plus le temps passe, et plus les demandes prennent du temps. Fini l’époque ou en quelques heures on pouvait faire évoluer le site. Maintenant, la moindre demande demande des jours… voir des semaines. Vous avez perdu la flexibilité.

En plus des tensions sont apparues entre les équipes. Le marketing estime que la technique « se moque du monde ». La réciproque est bien sûr vrai également….

Bref, la belle machine est grippée.

Que c’est il passé ?

La raison, c’est la « dette » : à force de faire évoluer le logiciel, par petites retouches, le code est devenu un plat de nouille, un « machin » extrêmement complexe. Personne en fait n’en a plus la maîtrise. L’équipe technique a voulu répondre à toutes les demandes, et à voulu répondre vite. Elle a donc accepté des « écarts » en terme de qualité : elle a codé rapidement, quite à faire du « copier coller » pour aller plus vite.

A force d’empiler les écarts, jours après jours, le code est devenu instable, extrêmement complexe.

En plus, bien souvent, les équipes ont tournées. Certaines parties du code ne sont plus vraiment maîtrisées.

A ce stade, les choses sont difficile.

Ce scénario, je l’ai vu des dizaines de fois.

Alors, comment l’éviter ?

C’est difficile 😉

On peut dire plusieurs choses :

Il est normal d’avoir un échange, une « négo » entre la technique et le métier. Si la négo est systématiquement qu’il faut faire vite, quelque soit l’impact sur la qualité, alors il faut pas s’étonner du résultat…
Il faut une équipe technique ayant un bon niveau, technique bien sûr, mais également « management », pour être capable de maîtriser ces enjeux, d’avoir de la hauteur de vue, et être capable de bien réfléchir aux conséquences des évolutions, et aux pistes pour ne pas plonger dans le capharnaüm.
Il faut des interlocuteurs métiers et direction « ouverte », à l’écoute des enjeux technique : seule façon de prendre en compte ces aspects.

C’est un sujet clé, qui mériterait… un livre 😉

Microsoft – Nokia : La fin des pur player software ?

Toute l’intelligence de Microsoft, à ses débuts, ça a été de comprendre avant tout le monde, que

le logiciel, c’est un composant clé des ordinateurs,
on peut faire du logiciel un business (très) rentable
on peut développer du logiciel de manière relativement indépendante des constructeurs d’ordinateurs

(à une époque ou un grand constructeur Français, Thomson pour ne pas le nommer, avait réussi l’exploit de sortir un ordinateur … sans OS 😉 )

D’autres très très grands éditeurs de logiciels ont émergés, soit pour le grand public (Google, Facebook, Adobe) soit pour les pros (SAP, Oracle, Adobe).

Les récents mouvements vont dans l’autre sens :

Apple s’est développé sur un modèle très intégré soft +hard
Google a racheté Motorola
Microsoft vient donc de racheter la branche téléphonie de Nokia (bon, c’était une affaire, à 5,4 Md €)

Assiste-on à la fin du modèle séparé éditeur – constructeur ?

Difficile à dire mais ces mouvements, quand on prend du recul, sont étonnant. Il faut bien voir que le moteur principal de tout ça, c’est le modèle économique, qui évolue vers la publicité. Et pour gagner de l’argent avec la pub, il faut maîtriser l’affichage du terminal…

On aurait pu penser que le tout internet allait au contraire renforcer la séparation soft – hard…

A suivre :

Facebook va-t-il vraiment se développer avec son propre smartphone ?
Microsoft va-t-il réussir à créer de la valeur avec Nokia ?
Même question pour Google (la preuve n’est pas encore faite) ?
Adobe va-il racheter … HTC ou Lenovo ? 😉
Les opérateurs vont ils entrer dans la danse et racheter des constructeurs, afin de remonter dans la chaîne de valeur ?

2013, 7ème année pour ce blog… et année 0 pour une nouvelle page…

Comme vous vous en doutez si vous lisez ce blog, et en particulier cet article, j’ai créé une nouvelle boite.

Je n’en parle pas, enfin presque pas ( 😉 ), car je pense que c’est trop tôt : le produit n’est pas complètement sec ;).

Voici quelques éléments :

Le domaine, devinez… Oui, le e-commerce, bravo !
La mission : améliorer la performance des sites e-commerce (d’accord, on n’est pas les seuls…).
Le métier : éditeur de logiciel, en mode SAAS.

Cela donne un cadre assez précis en fait 🙂

Je suis convaincu que le SAAS est un mouvement de fond, et que petit à petit, ce mode va se généraliser. C’est inévitable car les e-marchands ont et auront de moins en moins le temps, l’argent pour faire autrement.

Quand à l’augmentation de la performance commerciale, c’est évidemment un sujet complètement clé, quand on voit l’évolution des prix d’acquisition des clients.

Bref, un beau projet. Je vous en dirais plus bien vite.

En attendant je vous souhaite une bien belle année 2013 :

Que les meilleurs moments de 2012 soient les pires de 2013 (elle n’est pas de moi mais je l’aime bien 😉 )

Faire du logiciel, du développement, c’est de l’artisanat

Je déjeunais ce midi avec un ami de longue date.

On échange souvent sur le développement logiciel (entre autre sujets, je vous rassure 😉 )

Notre conviction commune, c’est que faire du logiciel, du développement, c’est un processus artisanal et pas industriel.

Je me suis déjà exprimé là dessus.

Dans la pratique, dans mon (mes ?) métier(s), quand je dis ça, je sens bien que c’est « contre productif » :

Les boites qui vendent du « processus industriel » à tour de plaquettes commerciales se sentent agressées, et se défendent en m’agressant à leur tour ;
Les clients qui connaissent mal tout ça (et c’est bien normal, ce n’est pas leur métier) se disent que l’artisanat, ça fait moins pro que « processus industriel ».

D’un point de vue rationnel, pourtant, c’est assez basique :

Un processus industriel, cela consiste à fabriquer un produit, avec un processus bien défini, qui permet d’accélérer la production, et de multiplier le nombre de produits fabriqués, en garantissant que tous les produits sont bien conforme au cahier des charges, tout cela avec un coût maîtrisé.

Cela passe par une séparation très forte, entre différents métiers.

L’ingénieur, qui conçoit le processus, décompose la chaîne de fabrication, et conçoit des machines, qui permettront de reproduire les mêmes actions, rapidement et sans faute.

De l’autre côté de la chaîne (c’est le cas de le dire), l’ouvrier derrière la machine a un travail répétitif, travail qui est d’ailleurs de plus en plus souvent remplacé par des machines, des robots.

Dans le monde du logiciel, cela n’existe pas, et, pire, quand on tente d’appliquer de telles méthodes, on arrive à des catastrophes.

Au final, ce qui marche, au contraire, c’est le recrutement des meilleurs développeurs, et de leur confier des missions ou ils pourront avoir le maximum d’autonomie.

On est donc bien dans un processus artisanal, ou ce qui compte, c’est la qualité de l’artisan.

Un exemple parmi des centaines :

Apple a eu besoin de 60 personnes pour créer iOS.

Motorola, qui essayait de faire la même chose, avait mis sur les rang 1500 personnes.

Qui a réussi ?

On est donc dans une industrie ou ce qui compte, c’est la grande qualité de quelques personnes clés. Et je ne parle pas des managers, mais bien des développeurs !

Quand tu veux Yves, pour poursuivre ce passionnant sujet 😉

Les métiers du développement

Le e-commerce s’appuie sur le logiciel.

Il s’agit donc de bien maîtriser ce métier… Ces métiers en fait !

Comment un développeur peut évoluer ?

En fait, il peut évoluer de plusieurs façons.

Il peut poursuivre dans une voie technique, prendre de la hauteur de vue, et devenir un architecte.

Un architecte, c’est un gars qui a une culture technique très large, et qui, à l’écoute des différents besoins et contraintes techniques, propose des solutions adaptées. C’est un rôle tout à fait fondamental.

L’architecte garde donc une maîtrise technique, il doit coder. Vis à vis des autres développeurs, il est un « référent ». Pas de relation hiérarchique, mais un rôle d’expert, que l’on consulte.

L’autre voie, c’est le chef de projet bien sûr. Il s’agit d’une évolution moins technique, pour aller vers le fonctionnel et le management. Le chef de projet encadre, gère le planning, et est en « tête de pont » pour les relations avec le client, interne ou externe.

Le métier de chef de projet est souvent bien compris, bien reconnu, et présent sur les projets.

C’est moins le cas pour l’architecte, et, de mon point de vue, cela fragilise bien des projets.

Le prix du logiciel : par rapport à ce que ça coute ou par rapport à ce que ça fait gagner ?

Encore un billet sur le prix du logiciel 😉

Il faut dire que c’est un vrai sujet !

Du point de vue de l’éditeur, a la base, la réflexion est simple : il faut vendre le logiciel le plus cher possible.

C’est bien le but de toute boite, de maximiser ses revenus, pas d’état d’âme là dessus.

Donc, vous avez une solution différente de ce qui se fait sur le marché, vous répondez à un vrai problème chez vos clients, vous pouvez faire payer un prix, à l’échelle du problème traité chez le client.

C’est logique, ça se tient.

Cela peut même créer un « prix de marché » si vous êtes avant les autres, et les autres utiliseront votre référence pour s’aligner, se comparer.

C’est comme ça que l’industrie du logiciel a un « pricing » basé sur des critères plus ou moins rationnels…

Ce prix n’est pas lié aux coûts de productions, de R&D en par exemple.

Le problème, car il y a un problème, c’est que vous créez, mécaniquement, une opportunité.

Vous créez une opportunité car, si il y a un grand décalage entre le prix de vente du logiciel, comparé aux coûts de de productions, un autre acteur peut rentrer sur le marché, et « faucher plus raz ».

A l’extrême, c’est ce que font les éditeurs de logiciels « open source », qui proposent une solution non pas gratuite, mais bien moins cher que les autres solutions du marché (je pense à des Talend, Sugar CRM, …).

C’est une extrême, je trouve, car on se retrouve avec une autre distortion : on vend le logiciel à un prix très très faible, et on espère vivre sur le conseil, le service à haute valeur ajoutée.

Ca peut marcher (talend ou sugar CRM…) mais c’est un peu « tordu ».

Je préfère, si j’ai le choix, un modèle plus « franc du collier », avec un prix en lien avec la R&D donc.

Là, on entre dans une autre discussion : comment répercuter le prix de la R&D sur du logiciel, puisque la vente de ce logiciel ne va pratiquement pas engendrer de coûts de production (ce qui n’est pas le cas, par exemple, pour une voiture 😉 ).

La réponse est simple :

On sait a qui on doit vendre son logiciel, la cible donc.

On estime la part du marché accessible, bref, on estime le nombre de licence qu’on va vendre.

A partir de là, on peut calculer le prix de vente du produit (R&D + coûts opérationnels + coûts marketing + marge).

Cela veut dire qu’il y a un lien entre la cible et le prix.

Et c’est logique : un logiciel distribué à des milliers de clients n’a pas le même prix que s’il est vendu à 3 exemplaires.

La flexibilité des prix, je trouve que c’est un sujet passionnant.

Regardez ce qui se passe sur les jeux pour iPhone :

Le prix des jeux était, en moyenne, pour les consoles, autour de 30 / 45 €.

Ce prix a complètement été revu, sur l’iPhone.

Les meilleurs jeux sont à moins de 10 € !

Mais les volumes ne sont pas les mêmes, la cible n’est pas la même, les circuits de distribution non plus.

Cette souplesse, cette réactivité, n’a pas été copié sur d’autres secteurs, qui devraient pourtant en prendre de la graine !

Les gros projets qui font plouf !

Pourquoi les très gros projets Internet sont souvent des échecs ?

On entend régulièrement parler de projets, ou le prix était de plusieurs millions d’euros, et qui se sont mal terminés… très mal pour certains.

Dernier exemple en date : France.fr.

Comment est-ce possible ?

Ou est le « bug » ?

Si on compare avec le bâtiment, cela ne se passe pratiquement jamais comme ça.

Bien sûr, dans le bâtiment, les délais dérapent, les prix aussi… Mais le truc se monte, et bon, on arrive à un bâtiment qui souvent correspond à peu près à ce qui était demandé initialement.

Alors, pourquoi n’en est-il pas de même avec le software ?

Je pense que le coeur de la réponse, c’est la jeunesse de cette industrie, et donc les erreurs de jeunesses, de la part de … plus ou moins tous les acteurs impliqués.

Le client :
Il ne connait pas forcément la différence entre une demande raisonnable et une demande extrêmement complexe. Alors que, pour reprendre notre analogie avec le batiment, certaines demandent seraient balayées dès leur expression (« je veux une piramide à l’envers : heu, non ! »)
Il n’a pas non plus forcément conscience qu’on ne peut pas faire évoluer les demandes au fil de l’eau, pendant les développements.
Enfin, il ne va pas forcément s’adresser à la bonne adresse. Il va s’adresser aux plus gros cabinets de conseils, ou aux très grosses SSII.
Ces sociétés ne sont pas spécialisés sur Internet, et finalement, n’ont pas réellement l’expertise technique nécessaire.

La société en charge du projet :
Comme je l’ai dit plus haut, c’est bien souvent une très grosse boite, de conseil ou d’informatique.
Elle n’est pas particulièrement spécialisée sur les architectures Internet.
Elle va donc appliquer des méthodes inadaptées.
Et le problème avec l’informatique, c’est que les erreurs de conceptions, on les voient bien souvent à la fin du projet…

Et voila, c’est simple finalement :
Le client et le prestataire appliquent des recettes inadaptées.

Le web est neuf, il faut travailler avec des boites pointues, des spécialistes.

Mais bon, aucune chance que cet article change les choses, puisque de tels décideurs ne sont pas lecteurs de ce type de blogs.

Et les rares à lire ces lignes savent déjà ce que je viens de dire 😉

Le prix du logiciel

Quand on achète une voiture, il y a un lien entre le prix payé et le cout de production.

On achète la R&D, l’usine de fabrication, les hommes qui passent du temps, la chaîne de distribution, le marketing.

Ajouter une petite marge, et hop, vous avez le prix de votre voiture.

C’est tout pareil pour l’électronique, sauf que dans ce cas, les marges sont ridicules.

Dans le monde physique, il existe des domaines ou le prix de vente est complètement débranché du prix d’achat. Il s’agit bien sûr du domaine du luxe.

Le travail marketing crée la valeur.

Le client achète du rêve, de l’image… Et le prix d’achat n’a plus rien a voir avec le prix de fabrication.

Bon, et dans le logiciel ?

Dans le monde du logiciel pro, bien souvent, les règles pour calculer les prix sont basés sur différents critères : puissance des serveurs, nombre de transactions, nombre de produits stockés dans le système, …

Quel est le rationnel derrière tout ça ?

Le logiciel coûte-t-il plus cher si il tourne sur plus de serveurs ?

(on ne parle pas de logiciels en mode SAAS, c’est un autre sujet)

Donc, non, il n’y a derrière ce type de prix qu’une seule logique : celle qui consiste à dire :

« Si vous utilisez plus mon logiciel, vous gagnez plus d’argent avec, et donc vous payez plus. »

Un responsable marketing d’une boite de soft me disait que le vrai bon prix, c’est de prendre un pourcentage sur le chiffre d’affaires du client.

Du point de vue de l’éditeur, qui veut gagner plus d’argent, je comprends bien la logique.

Je la comprends bien aussi parce que je me suis trouvé, avec Wokup et Medience, à traiter ce type de sujet.

Mais je n’ai, au fond, jamais été à l’aise avec ce type de pricing.

Pas à l’aise parce que cela ne repose sur rien, à part sur le fait que, en tant qu’éditeur, vous voulez gagner le plus d’argent possible.

Et pour les éditeurs, cette stratégie conduit régulièrement à se faire « ratisser par le bas », avec des acteurs qui attaquent le marché avec une offre open-source, gratuite ou très peu cher.

Je ne pense pas que ce type de pricing va perdurer très longtemps.

Je pense qu’à terme, le marché ira vers un pricing raisonnable.

C’est quoi ça ?

C’est simple : un prix en relation avec les coûts liés à la production du logiciel.

Pour écrire un logiciel, il faut investir en R&D.

Puis, une fois le logiciel sorti, il faut poursuivre les investissements, pour améliorer le produits.

Vous pouvez donc estimer vos coûts, et en estimant le nombre de clients cibles, vous pouvez définir un prix de vente.

Bien sûr, avec ce type de calcul, le prix sera très variable en fonction du marché adressé. Plus vous diffuserez largement votre logiciel, et moins il coûtera cher (modulo les coûts marketing, plus élevé en cas de distribution large…).

Vous vous retrouvez dans une situation saine, ou votre prix est raisonnablement lié aux coûts.

Autre article sur le sujet :