PHP fait tourner 77% du web. Pas parce que c'est à la mode — parce que ça marche, c'est déployable partout, et ça tient en production depuis 30 ans. Du formulaire de contact au back-office complet, du site WordPress à l'API REST : PHP reste le pilier du développement web côté serveur.
19 ans de PHP en production : j'ai traversé chaque évolution majeure du langage depuis les premières versions — PDO, namespaces, Composer, PHP 7 et ses gains de performance x2, jusqu'à PHP 8 avec les attributs, les fibres, les types stricts et les enums. Une expérience qui se traduit par des décisions architecturales fondées, pas des choix dictés par les tendances du moment.
Je ne choisis pas un framework parce qu'il est populaire sur GitHub, mais parce qu'il répond au problème posé. Un site vitrine dynamique n'a pas besoin de Laravel — un micro-framework ou du PHP natif bien structuré fait le travail en 10x moins de code. Une application métier complexe, en revanche, bénéficie d'un framework MVC structurant.
J'ai vu passer les modes : l'obsession MVC, puis les micro-services à tout prix, puis le serverless, maintenant l'IA. PHP reste. Il évolue, il se modernise, il performe. Et surtout : il a un écosystème mature, une communauté massive, et un déploiement trivial sur n'importe quel hébergement.
Conception d'APIs RESTful propres et documentées : routing structuré, validation des données entrantes, authentification JWT ou API keys, pagination, filtrage, gestion des erreurs avec codes HTTP corrects. Documentation OpenAPI/Swagger générée depuis le code. J'ai construit des APIs qui servent des applications React, des apps mobiles, des dashboards, et des workflows n8n.
Outils de gestion de stock avec alertes de seuil, CRM simplifiés avec pipeline de ventes visuel, systèmes de réservation avec gestion de créneaux et conflits, tableaux de bord de suivi d'activité avec graphiques temps réel. Chaque outil est pensé pour les gens qui l'utilisent au quotidien — pas pour le décideur qui l'a commandé et ne l'ouvrira jamais.
Conception de schémas relationnels MySQL/MariaDB normalisés, index optimisés pour les requêtes fréquentes, procédures stockées quand c'est pertinent, migrations versionnées. J'ai optimisé des requêtes qui prenaient 8 secondes pour les ramener à 50ms — le problème n'est jamais "MySQL est lent", c'est toujours le schéma ou la requête.
Envoi transactionnel via Brevo, Mailgun ou SendGrid avec templates HTML brandés. Traitement de webhooks entrants (Stripe, PayPal, Shopify). Connexion à des APIs tierces : CRM (HubSpot, Pipedrive), logistique (Colissimo API), SMS (Twilio), stockage (AWS S3). Chaque intégration est gérée avec retry, timeout et fallback.
Import/export de données CSV/XML/JSON, synchronisation entre systèmes (ERP → site web, CRM → email marketing), crons de nettoyage de base, génération de rapports automatiques, traitement de fichiers volumineux en mode chunk pour éviter les dépassements de mémoire. Les tâches ingrates automatisées proprement, avec logs et notifications en cas d'erreur.
Votre développeur précédent est parti, le code n'est pas documenté, ça tourne mais personne n'ose y toucher. Je reprends le code existant : audit technique, documentation du fonctionnement actuel, correction des failles de sécurité critiques (injections SQL, XSS), puis refactoring progressif. Pas de réécriture totale si ce n'est pas nécessaire — on modernise ce qui doit l'être.
Le PHP mal écrit est un vecteur d'attaque classique. Les failles les plus courantes que je corrige et préviens :
Utilisation systématique de requêtes préparées (PDO). Aucune concaténation directe de variables dans une requête SQL. Validation et typage strict des données entrantes avant toute interaction avec la base.
Échappement systématique des sorties HTML (htmlspecialchars), Content Security Policy configurée, validation des données utilisateur côté serveur. Les données ne sont jamais affichées brutes dans le DOM.
Tokens CSRF sur chaque formulaire, sessions sécurisées (httpOnly, secure, SameSite), hashing bcrypt pour les mots de passe (jamais MD5 ou SHA1), politique de renouvellement de session après login. Protection brute-force sur les endpoints d'authentification.
Le back-end PHP ne vit pas seul. Je maîtrise toute la chaîne : du serveur Apache/Nginx au navigateur du client. HTML sémantique, CSS responsive, JavaScript moderne, appels AJAX/Fetch, rendu dynamique côté serveur ou côté client selon le besoin.
L'avantage d'un développeur full-stack : un seul interlocuteur qui comprend les contraintes des deux côtés. Quand le front a besoin d'une donnée formatée différemment, je ne crée pas un ticket pour le back-end — je modifie l'API et le composant front dans la même session. Pas de ping-pong entre deux équipes.
Pour les projets qui le justifient, je sépare proprement le front (React, Vue, ou vanilla JS) et le back (API PHP). Pour les projets plus simples, le rendu côté serveur PHP avec du JS léger en complément reste la solution la plus efficace et la plus maintenable.
Que ce soit un nouveau développement ou la reprise d'un existant, le processus est le même : comprendre d'abord, coder ensuite. Je ne commence pas à écrire du code avant d'avoir compris votre métier, vos utilisateurs, vos flux de données.
Pour un nouveau projet : on cadre le périmètre, je propose l'architecture technique, on valide ensemble. Le développement avance par modules fonctionnels livrés et testés. Vous avez accès à un environnement de préproduction en permanence.
Pour une reprise de code : je commence par un audit — lecture du code, identification de la dette technique, cartographie des risques de sécurité. Je vous livre un rapport priorisé : ce qui est critique (failles de sécurité), ce qui est important (performance), ce qui peut attendre (refactoring esthétique). On traite dans l'ordre.
Dans les deux cas : le code est versionné sous Git dès le premier jour, les déploiements sont documentés, et vous recevez l'intégralité du code source. Pas de code propriétaire, pas de vendor lock-in.
Compréhension de votre activité, de vos flux de données, de vos contraintes. Définition du périmètre fonctionnel et technique. Choix de la stack (framework ou vanilla, type de base, hébergement).
Schéma de base de données, structure des fichiers, définition des endpoints API si applicable. Cette phase prend du temps — et c'est normal. Une bonne architecture se paye une fois, une mauvaise se paye à chaque évolution.
Chaque fonctionnalité est un module isolé : développé, testé, livré. Authentification, CRUD principal, intégrations tierces, back-office, front-end — dans cet ordre généralement.
Tests fonctionnels, vérification des failles courantes (OWASP Top 10), test de charge si pertinent, audit des performances SQL. Le code part en prod propre.
Mise en production, configuration serveur, documentation technique (schéma de base, procédures de déploiement, dépendances). Transfert des accès complet.
Mission accomplie : boutique Shopify livrée dans les délais, SEO configuré proprement dès le départ. Trois mois après le lancement, on commençait à ranker sur nos requêtes cibles sans avoir touché à la pub.
J'avais un CRM maison codé à la va-vite il y a 8 ans, plus personne ne voulait y toucher. Reprise de code complète, sécurisation, ajout de l'API n8n pour automatiser les relances. Ça tourne sans problème depuis.
Workflow n8n pour automatiser nos rapports hebdomadaires — ce qui prenait 3h à une personne chaque vendredi est maintenant généré et envoyé automatiquement. Setup propre, bien documenté.
Du script utilitaire à l'application métier — envoyez votre brief, je reviens avec une proposition technique.
info@codxp.frRéponse sous 48h · Devis gratuit · Pas d'engagement
Un échange de 30 à 60 minutes pour cerner vos besoins, évaluer la faisabilité et vous proposer une approche concrète. Sans engagement, sans jargon.
Basé à Grenoble · Interviens partout en France · Réponse sous 24h