Discussion :

[Bobo159]

Bonjour tout le monde,

d'abord je ne sais pas si c'est le bon endroit pour poster, si ce n'est pas le cas je demande au mods de deplacer la discussion au bon endroit, merci. Je suis développeur C# (WPF, donc client lourd) et je me suis en train de me reconvertir en développeur web (plutôt PHP,Mysql,Symfony, etc..). On a un module "entrepreneuriat digital", ou en gros on apprend a monter une start up, trouver des financements, etc...
On a debuté ce module, dans lequel on a de l'argent virtuel, une start up virtuelle et on nous a tous donné un premier exercice dans lequel on nous demande après voir choisi le nom et l'emplacement de la start up de choisir une stack technique. Ayant appris le php/mysql je me suis dit je choisis le stack LAMP (Linux, Apache, Mysql, PHP), mais je me rends compte que ce n'est pas aussi facile. Une de conditions est que l'application qu'on souhaite "developper" dans cet exercice doit être scalable (gerer plusieurs users, plusieurs connexions en même temps, etc..) et on devrait pouvoir gérer beaucoup des données (une énorme quantité de données dans la Base de données si j'ai bien compris l'exercice) sur le long terme, donc je me dit peut-être que le stack LAMP n'est peut-être pas adapté. De plus il faut argumenter du pourquoi du choix du stack, donc ce n'est pas un exercice facile. On a bien sur le droit de se renseigner sur internet. J'ai jamais eu a choisir un stack technique, donc je vous demande vous tous les développeur (ou pas d'ailleurs) comment vous choisirez votre stack technique et le pourquoi? Cela me permettra de m'aider à choisir mon propre stack sur cet exercice.

Merci beaucoup,
Bob

[fluctus]

Bonjour,

Je dirais que les critères de choix d'une stack varient en fonction du type de CTO :

1. le lead dev/CTO "niveau 1" va souvent choisir sa stack en fonction des technos qu'il maîtrise
2. le CTO/urbaniste "niveau 2" va généralement choisir sa stack en essayant d'assurer la scalabilité de sa solution
3. le CTO/manager "niveau 3" va presque toujours ouvrir une concertation avec ses lead dev et/ou architectes.

Pour moi, il faut aussi tenir compte des aspects suivants :

• recrutement (facilité et coûts pour trouver des dev pour ces technos, dans ta zone de recrutement, et au niveau d'expérience nécessaire à l'application)
• vitesse de développement/itération
• coût d'investissement, y compris celui dans les outils de développement et les besoins machine pour l'exploitation
• standards du marché (pour faciliter la revente de la startup : l'acheteur sera plus difficile à convaincre s'il doit assumer des choix techniques "exotiques", qui lui sembleront plus risqués).

Comme tu es dans un contexte d'entreprenariat digital, au stade d'une startup débutante, je pense que le critère le plus important pour ton choix se situe dans la vitesse d'itération.
C'est une condition de survie pour une startup au stade du MVP, donc dans les étapes customer validation - customer creation du customer development. Il va falloir faire itérer rapidement le MVP vers un MLP et générer de la traction, des ventes, pour survivre et grossir (ou attirer des investisseurs).

Que tu choisisses une stack avec un backend .Net ou PHP, ces technos sont capables de monter en charge.
En termes de recrutement, on trouve peut-être un peu plus facilement des dev PHP que C#.
En termes d'investissements, au tout début l'avantage est probablement côté PHP, mais passé une certaine échelle l'écart de coût avec des solutions propriétaires s'amenuise.
Les 2 stacks sont crédibles pour revendre ta startup d'ici quelques années, avec peut-être un avantage côté PHP (parfois plus facile à maintenir et moins prompte à l'obsolescence).

• Pour une solution web, PHP est un "no brainer", que l'on soit sur un segment B2C ou B2B, y compris pour du SAAS.
• Les stacks Microsoft se rencontrent généralement chez des PME éditrices de logiciels B2B, qui privilégient l'investissement dans les équipes backend plutôt que sur le frontend.

Ces dernières privilégient généralement une architecture monolithique, là où les adeptes des API/micro-services/micro-frontends se tournent plus facilement vers des technos web natives (PHP, NodeJS...).

C'est d'ailleurs le piège du hype driven development dans la communauté web : copier les architectures des grands du web (Google, Facebook), alors que son entreprise n'a absolument pas ces besoins.
De la même façon que par le passé, les partisans de dotNet se sont laissés séduire par les sirènes SOA/SOAP...