Agence web PHP
Feel and Clic est une agence web fondée il y a plus de 16 ans. Depuis le début, PHP occupe une place centrale dans notre pratique, porté par une conviction construite dans la durée. Nous avons accompagné l’évolution du langage version après version et capitalisé sur cette expérience pour affiner nos méthodes.
Ce recul nous a permis de renforcer une approche claire : la qualité d’une application repose avant tout sur la justesse des décisions prises à chaque étape du projet architecture, tests, documentation et gestion de la dette technique.
Aujourd’hui, PHP 8.x est un langage moderne, typé, performant et soutenu par un écosystème de premier plan. Il propulse des plateformes critiques dans des secteurs exigeants : e-commerce à fort volume, applications métier, SaaS B2B, portails institutionnels. Notre rôle n’est pas de vous convaincre d’utiliser PHP c’est de vous livrer des applications qui tiennent dans le temps, que vos équipes peuvent maintenir et faire évoluer sans nous.
Le périmètre exact de notre service PHP
Notre intervention couvre l’ensemble du cycle de vie d’une application PHP : de la conception à la mise en production, de la reprise d’un projet existant à sa modernisation progressive. Nous travaillons sur des projets à périmètre défini comme en accompagnement long terme. Ce qui ne change pas d’un projet à l’autre, c’est notre niveau d’exigence sur la qualité du livrable.
Développement d’applications PHP 8.x sur mesure : Nous concevons et développons des applications métier complexes back-offices, APIs REST et GraphQL, plateformes SaaS, systèmes de gestion interne, moteurs de règles métier. Chaque projet est architecturé pour durer, pas pour tenir jusqu’à la prochaine refonte.
Reprise et maintenance de bases de code existantes : Nous intervenons sur des projets que nous n’avons pas commencés y compris des bases legacy complexes, sous-documentées ou mal testées. Nous commençons par un audit rigoureux avant de proposer quoi que ce soit.
Migration et modernisation : Passage de PHP 5 ou 7 vers PHP 8.x, remplacement de frameworks en fin de vie, découpage d’un monolithe en composants indépendants, introduction progressive des types stricts et des attributs PHP 8. La migration se fait sans interrompre la production.
Développements autour de CMS PHP : Extensions et modules sur mesure pour WordPress, Drupal ou Sylius en respectant l’architecture native du CMS, sans accumulation de plugins tiers qui créent de la dépendance et de la vulnérabilité.
Audit de sécurité et renforcement applicatif : Revue du code sous l’angle OWASP Top 10, détection et correction des failles d’injection, mauvaise gestion des sessions, exposition de données sensibles, configuration serveur défaillante. Livrable : rapport priorisé avec plan de remédiation.
Notre approche technique
Stack et frameworks
Nous travaillons exclusivement sur PHP 8.1, 8.2 et 8.3. Pour le framework applicatif, nous utilisons Symfony 6 et 7 ou Laravel 11 selon la nature du projet. Symfony s’impose pour les applications métier qui demandent une architecture fine, une injection de dépendances rigoureuse et une forte maintenabilité sur le long terme. Laravel est privilégié quand la rapidité de développement est un enjeu et que l’écosystème Eloquent/Nova apporte une valeur concrète. Nous ne mélangeons pas les deux sur un même projet et nous justifions systématiquement notre choix en phase de discovery.
Côté persistance, nous utilisons MySQL ou PostgreSQL selon les besoins transactionnels et la charge attendue. Redis intervient pour le cache applicatif, la gestion des sessions et les files d’attente. Elasticsearch ou OpenSearch pour les besoins de recherche full-text avancée. RabbitMQ ou Redis Streams pour les architectures événementielles qui nécessitent un découplage des traitements asynchrones.
Qualité et standards de code
Chaque base de code que nous livrons respecte les conventions PSR-12 et est analysée par PHPStan au niveau le plus strict le niveau 8 dès le premier sprint, pas en fin de projet. PHP CS Fixer est configuré et intégré au pipeline pour éliminer les écarts de style avant chaque commit. Les tests sont écrits avec PHPUnit et Pest, avec un taux de couverture cible défini contractuellement selon les zones à risque du projet. Nous distinguons les tests unitaires, d’intégration et fonctionnels et nous testons en priorité les règles métier, pas l’infrastructure.
Chaque merge request fait l’objet d’une revue de code par un pair avant d’être intégrée à la branche principale. Cette pratique n’est pas négociable, même sur des projets à ressources limitées c’est le filet de sécurité le plus efficace contre les régressions silencieuses.
CI/CD et environnements
Les pipelines d’intégration et de déploiement continus tournent sur GitHub Actions ou GitLab CI selon la plateforme du client. Chaque push sur une branche de travail déclenche automatiquement l’analyse statique, la suite de tests et le linting. Les environnements de développement, staging et production sont conteneurisés avec Docker et Docker Compose dès le démarrage du projet ce qui élimine les écarts de configuration entre machines et garantit la reproductibilité des builds.
Le déploiement en production se fait via Déployer, avec des stratégies de rollback automatisables en moins de deux minutes. Chaque déploiement est tracé, les variables d’environnement sont gérées hors dépôt via des coffres-forts secrets (Vault ou équivalent cloud-native). Nous ne déployons jamais en production sans avoir validé l’incrément en staging au préalable.
Comment un projet PHP se déroule chez Feel and Clic
Phase de discovery et cadrage
Aucun projet ne démarre sans une phase de discovery. Sa durée varie de deux jours pour un projet bien défini à deux semaines pour une application complexe ou une reprise de l’existant. Cette phase produit un document de cadrage technique validé des deux côtés : périmètre fonctionnel, contraintes techniques, choix d’architecture argumentés, risques identifiés et plan de charge estimé par poste. Sur une mission de reprise de projet, la discovery inclut un audit de code complet livrable autonome avec cartographie de la dette technique, évaluation des risques de sécurité et recommandations priorisées. Vous pouvez décider d’arrêter là si l’audit suffit à votre besoin du moment.
Architecture et conception
Avant d’écrire la première ligne de code fonctionnel, nous posons l’architecture. Cela inclut la modélisation du domaine métier, le choix des patterns structurants (DDD, CQRS, hexagonal selon la complexité), la définition des interfaces entre composants et services tiers, et l’identification des points de charge. Un schéma d’architecture est produit et présenté au client. Ce n’est pas une formalité, c'est le moment où les décisions coûteuses à changer plus tard sont prises en connaissance de cause.
Développement en sprints courts
Le développement est organisé en sprints d’une à deux semaines. Chaque sprint livre un incrément fonctionnel testable pas un composant technique isolé sans valeur visible pour le métier. Vous avez accès au dépôt Git dès le premier commit, à l’environnement de staging dès le premier déploiement. Il n’y a pas de phase longue sans livrable intermédiaire, pas de surprise à la démonstration finale. Les backlogs sont priorisés ensemble en début de sprint ce qui signifie que si vos priorités changent en cours de projet, l’organisation peut s’adapter sans tout remettre en question.
Tests, revues et assurance qualité
La qualité n’est pas une phase finale, elle est distribuée sur toute la durée du projet. Les tests unitaires et d’intégration sont écrits en parallèle du code fonctionnel, pas après coup. Les revues de code sont systématiques avant chaque merge. Des tests de non-régression automatisés protègent les fonctionnalités livrées dans les sprints précédents. Sur les projets à fort trafic attendu, des tests de charge sont planifiés avant la mise en production.
Livraison, déploiement et transfert
La mise en production est préparée comme une opération à risque maîtrisé : déploiement en staging validé par le client, plan de rollback testé, checklist de déploiement documentée. La documentation technique est livrée en même temps que le code architecture décisionnelle, documentation des APIs, procédures d’exploitation et de déploiement. Si votre équipe doit reprendre la main sur le projet, une session de passation est organisée.
Maintenance et évolutions
À l’issue du projet, un contrat de TMA (Tierce Maintenance Applicative) peut être mis en place. Il couvre la surveillance proactive des dépendances et des failles de sécurité, les montées de version PHP et des librairies tierces, les corrections de bugs en production et un volume mensuel de développement pour les évolutions courantes. Le volume est contractuellement défini, non reconductible tacitement et ajustable chaque trimestre selon l’activité réelle.
La relation client au quotidien
Un projet bien livré techniquement mais mal piloté reste une source de friction. Nous avons structuré notre façon de travailler pour que vous sachiez toujours où en est votre projet, qui est responsable de quoi, et comment faire remonter une décision ou un blocage.
Un interlocuteur technique identifié : Un développeur senior est responsable de bout en bout de votre projet. C’est lui qui participe aux réunions de cadrage, qui signe les choix d’architecture et qui livre le code. Pas de rotation d’équipe en cours de route, pas de junior présenté comme senior le temps de la vente.
Points de sprint hebdomadaires : Chaque semaine, un appel de 30 à 45 minutes : démonstration de ce qui a été livré, présentation du sprint suivant, levée des blocages et décisions en attente. Ce n’est pas un reporting c’est un moment de travail partagé.
Visibilité en temps réel : Accès au dépôt Git, au board de gestion des tâches (Notion, Linear ou Jira selon votre outillage) et à l’environnement de staging dès le début du projet. Vous n’avez pas besoin d’attendre un compte-rendu pour savoir où en est le projet.
Synthèse mensuelle écrite : Un document concis : ce qui a été livré, ce qui reste à faire, les risques actifs, les décisions en attente côté client et les éventuels écarts par rapport au plan initial.
Contractuel sans ambiguïté : Devis détaillé par poste, périmètre écrit noir sur blanc. Toute demande hors périmètre fait l’objet d’un avenant chiffré et validé avant exécution. Jamais de régularisation en fin de projet.
Escalade directe : Si un désaccord technique ou fonctionnel apparaît, il est traité immédiatement avec les bonnes personnes pas renvoyé à la prochaine réunion. Nous préférons une friction courte à un problème qui grossit en silence.
Ce que Feel and Clic apporte dans ses projets
Une expertise back-end concentrée, pas dispersée
Feel & Clic maîtrise le développement back-end PHP dans sa profondeur. Après plus de 16 ans de projets, nous savons ce que demande vraiment une architecture robuste, une base de code maintenable et un code qui résiste à l'épreuve du temps. Cette concentration sur le back-end se traduit concrètement dans la qualité de nos livrables : chaque décision d'architecture que nous prenons s'appuie sur des dizaines de situations réelles, des problèmes déjà rencontrés, des erreurs déjà évitées. Vous bénéficiez d'une équipe qui connaît son domaine en profondeur, pas d'une agence qui survole plusieurs spécialités sans en maîtriser aucune.
Une capacité prouvée sur les projets difficiles
Les projets que d’autres agences évitent les bases de code PHP 5 mal documentées, applications sans tests, dépendances obsolètes en cascade, architectures couplées impossibles à faire évoluer font partie de notre quotidien depuis des années. Nous savons poser un diagnostic honnête, distinguer ce qui peut être conservé de ce qui doit être réécrit, et construire un plan de modernisation qui ne bloque pas la production pendant les travaux. C’est une compétence difficile à acquérir et que beaucoup de prestataires préfèrent contourner en recommandant une réécriture complète.
Du code transmissible
Un livrable n’est bon que si quelqu’un d’autre que son auteur peut le lire, le comprendre et le faire évoluer. Conventions PSR strictement respectées, PHPDoc à jour sur les méthodes non triviales, architecture documentée, pas de raccourcis qui créent de la magie invisible. Quand nous quittons un projet, votre équipe interne ou votre prochain prestataire peut reprendre la main sans phase de déchiffrage.
FAQ : Agence web PHP
Pourquoi choisir PHP en 2025 alors que d’autres langages montent ?
PHP 8.x n’a plus grand-chose en commun avec le PHP des années 2000 qui a construit sa mauvaise réputation. Le langage dispose aujourd’hui d’un système de types progressif, d’attributs natifs, de performances proches de Node.js sur des benchmarks comparables, et d’un écosystème de frameworks Symfony, Laravel parmi les plus matures de l’industrie. Il propulse plus de 75 % des sites web mondiaux et des plateformes critiques comme Wikipedia, Shopify ou des milliers d’applications B2B en production. Le débat sur la pertinence de PHP n’est pas un débat technique, c'est un débat de perception. Nous travaillons avec PHP parce que c’est le bon outil pour la majorité des applications que nos clients ont besoin de construire ou de maintenir.
Pouvez-vous reprendre un projet existant que vous n’avez pas développé ?
C’est l’une des missions les plus fréquentes que nous réalisons. Nous commençons systématiquement par un audit de code indépendant, d’une durée de deux à cinq jours selon la taille et la complexité du projet. Cet audit produit un rapport structuré : cartographie de la dette technique, évaluation des risques de sécurité, identification des zones fragiles, recommandations priorisées avec estimation de charge. L’audit est un livrable autonome vous pouvez vous en servir avec d’autres prestataires si vous le souhaitez. Si vous décidez de continuer avec nous, les conclusions de l’audit alimentent directement le plan de travail.
Comment se passe la migration d’une application PHP 5 ou 7 vers PHP 8 ?
Une migration PHP majeure ne se fait pas d’un coup sauf si vous acceptez d’immobiliser votre application pendant des semaines. Nous travaillons en migration progressive : identification des incompatibilités bloquantes, mise en place de tests de non-régression sur les fonctionnalités critiques, migration par couche en maintenant la production opérationnelle à chaque étape. Nous utilisons Rector pour automatiser les transformations de code mécaniques et concentrons l’effort humain sur les décisions architecturales qui ne peuvent pas être automatisées. Le calendrier et le niveau de risque acceptable à chaque étape sont définis avec vous avant de démarrer.
Quelle est la différence entre Symfony et Laravel, et comment choisissez-vous ?
Symfony est un framework component-first, très modulaire, avec une courbe d’apprentissage plus raide mais une architecture qui supporte mieux la complexité métier sur le long terme. Il est particulièrement adapté aux applications avec des règles métier riches, des équipes multiples ou un besoin fort de découplage. Laravel mise sur la convention plutôt que la configuration, avec un écosystème de packages intégrés (Nova, Horizon, Sanctum) qui accélèrent significativement certains types de projets. Notre choix se fait en phase de discovery, selon la complexité fonctionnelle, la taille de l’équipe appelée à maintenir le projet et les contraintes d’intégration. Nous le documentons et l’argumentons ce n’est pas une préférence, c’est une décision technique.
Quel est votre délai de démarrage habituel ?
Deux à trois semaines après la signature du devis pour un projet standard. Ce délai n’est pas artificiel : il correspond au temps nécessaire pour préparer la phase de discovery correctement, allouer les ressources internes et mettre en place les environnements de travail. Sur des missions de maintenance urgentes ou d’audit ponctuel, nous pouvons intervenir plus rapidement. Si votre calendrier est contraint, dites-le nous dès le premier échange nous évaluerons ensemble ce qui est faisable sans compromettre la qualité du cadrage.
Comment gérez-vous la sécurité des applications que vous développez ?
La sécurité est traitée comme une contrainte transverse, pas comme une phase finale. En développement : respect systématique de l’OWASP Top 10, validation stricte des entrées, requêtes paramétrées sans exception, gestion sécurisée des sessions et des tokens, headers HTTP de sécurité configurés dès le déploiement initial. Les dépendances sont auditées avec Composer audit à chaque sprint. Sur les projets sensibles ou les applications exposées, nous proposons un audit de sécurité dédié en fin de développement avant la mise en production avec rapport de vulnérabilités et plan de remédiation.
Livrez-vous la documentation et dans quel format ?
La documentation technique est un livrable systématique, inclus dans le périmètre de chaque mission, pas une option facturée en supplément. Elle comprend la documentation de l’architecture décisionnelle (pourquoi ces choix, quelles alternatives ont été écartées et pour quelles raisons), la documentation des APIs avec Swagger/OpenAPI si l’application expose des endpoints, les procédures de déploiement et de rollback, et les guides d’exploitation à destination de l’équipe qui prend la main. Le format est adapté à votre outillage Notion, Confluence, fichiers Markdown dans le dépôt.