Le dev propose PHP et MySQL pour une appli web — c'est dépassé ou ça passe encore ?

Vos potes pensent sûrement au code spaghetti d'il y a 15 ans sur les vieilles versions de PHP. Aujourd'hui, PHP est fortement typé, ultra rapide et tout à fait testable pour des besoins pro. Assurez-vous simplement qu'il ne fait pas du PHP brut sans librairie et qu'il respecte une architecture MVC reconnue.

Dans le contrat avec le dev, faites bien écrire : 1) Le code hébergé sur un dépôt Git pro dont vous avez la pleine propriété, 2) Une base de données relationnelle bien structurée, 3) La livraison d'une doc d'installation et de la structure des données. C'est le manque de ces points-là qui bloque un projet, pas le langage.

PHP n'est pas mauvais mais les habitudes du dev comptent énormément. S'il essaie de vous refourguer son propre framework bricolé maison il y a 10 ans gros danger. Aucun dev sérieux ne voudra reprendre ce code plus tard et vous finirez par payer 80 GBP de l'heure en conseil pour réparer les pots cassés.

On a fait développer un portail de gestion d'entrepôt similaire il y a 4 ans, pile sous PHP et MySQL. Le serveur nous coûte même pas 15 pounds par mois. Ça tourne comme sur des roulettes pas un seul crash. Ne vous faites pas avoir par les effets de mode si c'est pour exploser votre budget.

Correction : je me suis trompé sur le chiffre, c'était un peu plus bas.

les devs adorent toujours encenser les derniers trucs à la mode. si ça fait le taf que c'est fluide et que le serveur coûte rien la techno passe au second plan. le plus important c'est que le dev disparaisse pas dans la nature après avoir livré le projet.

Au Royaume-Uni, le TJM d'un freelance sur des langages plus de niche tourne autour de 60-90 GBP de l'heure, alors qu'on trouve un bon dev PHP entre 40 et 65 GBP. Quand vous voudrez ajouter des fonctionnalités plus tard, ça préservera sérieusement votre trésorerie.

La réussite d'un projet dépend bien plus de la rigueur de l'analyse fonctionnelle que du langage choisi. Si vos processus métier sont parfaitement définis, les protocoles de sécurité en place et les sauvegardes automatisées, PHP et MySQL répondront à 100 % à votre besoin.

et si on veut connecter ce système à une appli mobile plus tard, PHP bloque le truc ou il faudra tout réécrire de zéro ?

edit : j'ai corrigé quelques fautes de frappe.

Exact. Quand on essaie de tout changer en même temps, rien ne prend.

C'est confirmé par l'expérience.

Chez nous aussi.

Je ne savais pas ça.

Je vais résumer ce qui a été dit jusqu'ici. Si vous ne formalisez pas cela par écrit dès le départ, des disputes éclateront plus tard.

Je le note au cas où.

Je suis d'accord, j'aimerais même souligner ce point. Si les critères d'acceptation ne sont pas écrits, la date de fin du projet est ouverte à discussion.

Le calendrier de paiement doit être lié aux étapes du projet, pas au calendrier lui-même. Bon courage.

Il faut y aller étape par étape. Plus il est difficile de revenir sur une décision, plus il faut la prendre lentement.

Bien sûr, cela change si votre situation est différente.

Vous avez raison. Mettre en place un processus de demande de changement n'ralentit pas le travail il l'accélère.

C'est mon avis, je ne l'écris pas comme une vérité absolue.

Nous avons vécu presque la même chose l'année dernière. Dans un système repris, le plus coûteux sont les dépendances inconnues.

Corrigez-moi si je me trompe.

Vous avez raison, je suis aussi passé par là. Quand on décide sans mesurer, on revient toujours au même point.

Si vous écrivez le résultat ici, cela aidera aussi d'autres personnes.

Mes doutes sont levés merci.