Boosté : Construire une application Laravel sans connaître Laravel

Dans ce tutoriel, vous apprendrez à construire un concierge de voyage WhatsApp via un agent d'IA en utilisant Laravel, OpenAI et l'API Messages API de Vonage.

WhatsApp chat interface showing the Vonage-powered travel concierge ready to receive and respond to user messages.

Introduction

TL;DR : Passez à l'étape suivante et trouvez le code de travail sur GitHub. code de travail sur GitHub.

Il y a quelques mois, Jim Seconde m'a demandé si je voulais écrire du contenu PHP. Jim est une célébrité de PHP depuis des années maintenant, touchant à peu près à tout ce qui concerne PHP sous le soleil. Mais moi ? Je n'ai pas touché à PHP depuis probablement 12 ans.

Jim m'a répondu : " Ne t'inquiète pas. Il y a ce nouveau truc cool appelé Laravel Boost. Il s'agit d'un serveur MCP spécifique à Laravel qui vous aide à créer des applications Laravel. Pas besoin d'éléphants. Peut-être que tu veux t'y mettre".

Cela s'est transformé en une petite expérience avec une contrainte très claire : pouvais-je construire une application Laravel non triviale dans une pile que je connaissais à peine, en utilisant un agent de codage IA comme principal outil de mise en œuvre ?

Je me suis lancé un défi délibérément difficile : créer un concierge de voyage WhatsApp en Laravel et PHP. L'application ne pouvait pas se contenter de renvoyer du texte. Elle devait recevoir des messages WhatsApp via l Vonage Messages APIutiliser OpenAI pour générer des réponses, choisir le bon type de message WhatsApp pour la réponse, prendre en charge des éléments interactifs tels que des boutons et des listes, et conserver suffisamment de mémoire de conversation pour donner l'impression d'être un assistant plutôt qu'un robot apatride.

Cela en a fait un cas de test utile. Il ne s'agissait pas d'une application CRUD jouet, ni d'un tutoriel sur le framework que je pouvais simuler. Elle impliquait des webhooks, des tâches d'arrière-plan, l'authentification d'API, des contraintes de plateforme externe et des formats de messagerie structurés.

Cet article n'est pas un tutoriel Laravel étape par étape. Il s'agit d'un rapport sur ce qu'a été la construction d'une application réelle de cette manière : quelles invites ont aidé, quelles phases ont permis de garder le travail sous contrôle, où l'agent a été utile, où il a échoué, et comment la documentation soutenue par MCP a changé le résultat lorsque les choses sont devenues difficiles.

L'ensemble du projet a pris environ huit heures sur deux jours. À la fin, j'avais une démo Laravel WhatsApp qui fonctionnait. Plus important encore, j'avais une idée beaucoup plus claire de ce à quoi le développement agentique est réellement bon.

Conditions préalables

• PHP

• Compositeur PHP

• Agent capable d'utiliser Laravel Boost (par exemple, GitHub CoPilot)

• Laravel Boost

• Compte API OpenAI ou autre LLM

• ngrok

• A vérifié Compte professionnel WhatsApp (WABA)

• Compte API Vonage

• Un numéro virtuel Vonage

Vonage API Account

To complete this tutorial, you will need a Vonage API account. If you don’t have one already, you can sign up today and start building with free credit. Once you have an account, you can find your API Key and API Secret at the top of the Vonage API Dashboard.

Ready to start building?

Experience seamless connectivity, real-time messaging, and crystal-clear voice and video calls—all at your fingertips.

Configuration de l'application Vonage

Vous devez activer les capacités de messages. Pour les messages, vous devrez activer les webhooks. Pour l'instant, il suffit d'ajouter des espaces réservés. Plus tard, une fois que l'application locale fonctionnera via ngrok, mettez à jour le webhook entrant pour qu'il pointe vers le point de terminaison de Laravel.

1. Définir l'URL entrant à https://placeholder.com/inbound.

2. Définissez l'URL de l'état comme suit https://placeholder.com/status.

Ensuite, reliez votre WhatsApp Business (WABA) en cliquant sur l'onglet "Lier des comptes externes" :

Vonage dashboard showing a WhatsApp Business Account linked to an application in the “Link external accounts” section.Veillez à noter les :

• ID de l'application

• Clé privée (téléchargée sous forme de fichier .key key)

• Clé/secret de l'API

Nous en aurons besoin plus tard pour notre application Laravel.

Configuration de l'agent

Dans un tutoriel normal, nous n'avons qu'à configurer notre application. Mais dans un tutoriel agentique comme celui-ci, nous devons également configurer notre agent.

J'ai utilisé un simple fichier d'instructions de type "plan-first" (copié sur le site de Alex Finn) :

1. Lisez la base de code et réfléchissez au problème.

2. Rédiger un plan dans todo.md.

3. Attendre l'approbation avant de commencer la mise en œuvre.

4. Effectuez les tâches une par une.

5. Expliquer les changements à un niveau élevé.

6. Les changements doivent être simples et minimaux.

Parallèlement, j'ai explicitement encouragé l'agent à utiliser deux outils soutenus par le programme MCP :

• Le MCP Laravel Boost MCP pour l'échafaudage et les conventions tenant compte du cadre.

• La documentation de Vonage Documentation de Vonage Serveur MCPpour l'exactitude de l'API et les détails du format des messages

C'est l'un des premiers enseignements clairs du projet : l'ingénierie des prompts est en réalité une ingénierie du flux de travail, et les outils MCP sont ce qui transforme ce flux de travail en quelque chose de fiable.

Tout d'abord, créez le fichier markdown qui contiendra vos règles :

touch ./github/instructions/workflow.instructions.md

Ajoutez ensuite les instructions conformément à la syntaxe des instructions du copilote. syntaxe des instructions du copilote :

4 étapes pour créer l'application

Lorsque j'ai commencé, je n'avais aucune idée du temps que cela prendrait ni de ce que cela impliquerait. Mais chaque fois que l'agent complétait une liste de tâches, je renommais le fichier et l'enregistrais. Je pouvais ensuite envoyer à l'agent les tâches terminées, ainsi que la portée initiale du projet, et il créait la prochaine série d'objectifs.

Au lieu de donner à l'agent de grandes instructions, je me suis concentré sur de petites phases avec des résultats clairs.

1. Construire l'application Laravel de base et l'intégration de WhatsApp

2. Ajouter des réponses WhatsApp à l'utilisateur à partir de l'application

3. Ajouter une mémoire de conversation pour de meilleures réponses de la part d'OpenAI

4. Ajouter des types de messages intelligents (boutons, listes)

Je résumerai ce qui s'est passé au cours de chaque phase et je mettrai en évidence les messages les plus intéressants.

Phase 1 : Laisser l'agent planifier l'application

Voir : initial_todo.md pour les tâches de l'agent.

La première invite était intentionnellement de haut niveau. J'ai décrit l'application de démonstration, l'intégration de WhatsApp et l'obligation d'utiliser OpenAI pour les décisions relatives au contenu et au type de message.

Initial prompt used to define the travel concierge app and guide the agent to generate a structured development plan using Laravel Boost and Vonage docs.

C'est là que Laravel Boost MCP a fait une différence notable.

Au lieu de produire une structure PHP générique, l'agent s'est immédiatement appuyé sur les conventions de Laravel. Il a suggéré des routes, des contrôleurs, des tâches en file d'attente et des classes de service d'une manière qui s'aligne sur la façon dont les applications Laravel sont généralement organisées. Il a également proposé un todo.md sans qu'on lui ait explicitement demandé de le faire.

L'agent utilisait les connaissances du cadre exposées par l'intermédiaire de MCP pour façonner l'architecture. Il a créé une route webhook, un contrôleur pour la validation, des tâches en attente pour le traitement et l'envoi de messages, et des classes de service pour OpenAI et Vonage.

Si j'avais travaillé sans expérience de Laravel, cela aurait pris beaucoup plus de temps à assembler manuellement. La première leçon à retenir est donc claire : lorsque l'agent a accès à un outil MCP conscient du cadre, il est très fort pour l'échafaudage greenfield.

AI-generated development plan outlining the Laravel WhatsApp app architecture, including webhooks, queue jobs, services, and OpenAI integration.

Le premier échec : Un code qui avait l'air correct mais qui ne faisait rien

La phase d'échafaudage s'est étonnamment bien déroulée. L'agent avait construit une application Laravel complète : routes, contrôleurs, tâches, services, et même un fichier de test. Avec Laravel Boost MCP guidant la structure, cela ressemblait à une vraie application bien plus tôt que prévu.

Les premiers problèmes sont apparus lorsque j'ai exécuté les tests que j'avais forcé l'agent à écrire.

L'un d'entre eux a immédiatement échoué :

The expected [App\Jobs\ProcessIncomingMessage] job was not dispatched.

Ce problème semblait plus facile à résoudre qu'il ne l'était en réalité.

L'agent n'a pas remonté la piste de l'échec jusqu'au contrôleur. Il est resté à la surface, spéculant sur la configuration et l'installation des tests, même si l'erreur était cohérente : le webhook a renvoyé une réponse, mais le travail n'a jamais été envoyé.

Après avoir examiné le test et le contrôleur côte à côte, il a finalement trouvé le problème. Le contrôleur a validé la demande et renvoyé une réponse, mais n'a jamais déclenché le reste du système. La solution tenait en une seule ligne :

ProcessIncomingMessage::dispatch($data['to'], $data['from'], $data['message']);

Après cela, le test a été réussi. Jusqu'à présent, l'agent avait été très efficace en matière d'échafaudage. Il produisait un code qui semblait correct et qui respectait les conventions du cadre. Mais il ne garantissait pas de manière fiable que le système se comportait de bout en bout.

En intégrant les tests dans le flux de travail, j'ai obtenu une version allégée du TDD. Le test définissait le comportement, et l'agent devait itérer jusqu'à ce que l'implémentation corresponde. Ce n'était pas une boucle sans heurts, mais cela m'a donné un signal stable sur lequel m'appuyer.

L'agent s'occupait du travail répétitif tandis que je me concentrais sur l'alignement avec le comportement attendu. C'est une façon idéale d'envisager la répartition du travail entre les agents et les humains.

Non pas parce que l'agent était parfait, mais parce qu'il a permis de soutenir plus facilement un projet tel que le TDD qu'il ne l'est habituellement à la main.

À ce stade, j'ai pu envoyer un message à l'appli et le voir enregistré dans le terminal :

[2026-03-09 17:15:00] local.INFO: WhatsApp webhook received {
  "from":"1***2364506",
  "to":"1***3508504", 
  "message_type":"text",
  "text_body":"Let’s test the Vonage WhatsAppp Service"
}

Phase 2 : L'application commence à parler en retour

Voir : second_todo.md pour les tâches de l'agent.

La structure de base était en place, mais il y avait un problème. Je ne recevais pas de messages en retour de l'application. Le flux aurait dû être le suivant : l'utilisateur envoie un message WhatsApp, il touche le webhook, passe par Laravel, reçoit une réponse d'OpenAI, puis repart par Vonage.

Il semblait que tout cela existait déjà. L'agent avait échafaudé les tâches, les services et les intégrations. Les messages parvenaient à l'application et rien n'était manifestement cassé. Mais cela ne fonctionnait toujours pas de bout en bout.

Échec en temps réel à la dernière étape

La première fois que le système a fonctionné jusqu'au bout, il a échoué en plein milieu du pipeline en raison d'une erreur d'exécution :

Sending message via Vonage {"to":"unknown","type":"text"}
Undefined array key "to"

Il s'agit d'un type particulier de défaillance qui n'apparaît qu'une fois que le système est en grande partie câblé. Parce que l'agent avait construit toutes les pièces de manière isolée, tout semblait correct. Et en amont, tout fonctionnait : le webhook a reçu le message, le travail a été envoyé, OpenAI a généré une réponse.

L'échec ne s'est manifesté que lors de l'envoi de la réponse. En regardant les journaux, le problème était subtil :

{
 "to": unknown,
 "type": "text"
}

Le système essayait d'envoyer un message sans véritable destinataire. Quelque part en cours de route, cette valeur a été perdue et remplacée par "inconnu". En effet, isolément, l'agent a fait en sorte que tout ait l'air bien, mais il a perdu de vue la vue d'ensemble et la façon dont tout cela est lié.

Le copilote n'arrêtait pas de réparer la mauvaise couche

C'est à ce stade que l'agent a commencé à éprouver des difficultés. Il n'a pas ignoré l'erreur. Il a continué à proposer des corrections. Mais encore une fois, ses propositions sont restées proches de la surface : ajuster les messages-guides, modifier la façon dont la réponse de l'OpenAI a été analysée, changer les formats de réponse

Toutes ces idées sont raisonnables, mais aucune ne s'attaque à l'échec réel. Le problème n'était pas de savoir comment la réponse était générée. Il s'agissait de la manière dont les données circulaient dans le système.

Trois choses se sont produites simultanément : le modèle a été autorisé à définir des champs tels que àles valeurs nulles passaient par plusieurs couches, et rien n'imposait de champs obligatoires avant l'envoi. Cette combinaison signifiait que le système n'échouait qu'à la toute fin, lorsque Vonage essayait d'utiliser les données.

Même après quelques itérations, l'agent n'a pas convergé vers ce résultat. Il a continué à produire des corrections plausibles qui n'ont pas changé le résultat.

Le changement d'agent a modifié l'approche

À ce moment-là, j'ai changé de CoPilot avec GPT-5 Mini à mon IDE préféré, Windsurf avec Claude Sonnetet je lui ai donné les logs complets au lieu de me contenter des erreurs. La différence n'était pas qu'il écrivait un meilleur code. Il a abordé le problème différemment. Au lieu de se concentrer sur la ligne défaillante, il a suivi tout le chemin du message :

webhook → OpenAI → job → Vonage

Il a ensuite ajouté des contrôles à chaque frontière : validation précoce des entrées, application des champs obligatoires avant l'envoi et enregistrement de l'état intermédiaire.

Le changement le plus important concerne l'étape de la validation. Jusqu'à présent, le système supposait que tout était valide et échouait tardivement. Après ce passage, il a commencé à échouer tôt, à des endroits prévisibles. Une fois ces contrôles en place, le problème "à" : "inconnu" a disparu.

Claude analyzing the error across the full message pipeline and applying validation at multiple layers instead of patching a single failure point.

L'agent a tenté de réinventer la roue

Une fois le flux de données corrigé, le système a progressé et a immédiatement rencontré le problème suivant. Les messages sortants échouaient toujours, mais cette fois avec un message 401 Non autorisé. La réaction de l'agent a été intéressante. Au lieu d'utiliser les outils existants, il a commencé à reconstruire la couche d'authentification à partir de zéro :

• générer manuellement des JWT

• à l'aide de openssl_sign()

• construire des jetons à la main

• l'envoi de requêtes HTTP brutes

En apparence, le code semblait raisonnable pour l'IA. Mais il n'a jamais fonctionné de manière fiable. Il s'agit d'un mode d'échec différent. Dans ce cas, il s'agissait de deviner comment fonctionnait l'authentification Vonage au lieu d'utiliser les conventions du SDK.

Le tournant : Forcer la documentation via MCP

La solution est venue d'une demande très directe :

Pourquoi n'avez-vous pas utilisé l'outil de documentation de Vonage pour générer un JWT via le SDK ? Nous n'arrivons pas à les créer manuellement.

Au lieu de continuer à improviser, l'agent a puisé dans l'outil MCP de documentation de Vonage et a changé d'approche. Il a utilisé le Vonage PHP SDKofficiel de Vonage, et a laissé le SDK gérer directement la génération des JWT.

Cela a permis d'éliminer complètement le problème.

Prompt that forced the agent to stop generating JWTs manually and use the Vonage documentation MCP tool and official SDK.

Phase 3 : Ajout de la mémoire de conversation

Voir : third_todo.md pour les tâches de l'agent.

Wahoo ! À ce stade, j'avais un chatbot WhatsApp de base qui fonctionnait. Mais il me paraissait très bête. Chaque message était traité isolément. L'assistant répondait correctement, mais il ne se souvenait pas de ce qui s'était passé auparavant.

L'objectif était simple : conserver l'historique des conversations, inclure les messages récents dans l'invite OpenAI et le faire d'une manière suffisamment simple pour ne pas introduire de nouvelle complexité.

Par rapport à la phase 2, il s'agit d'une extension directe.

Un premier passage en douceur

L'agent a mis en place une mémoire de conversation avec une base de données SQLite sans trop de difficultés.

L'agent a créé une Conversation et une table, a commencé à stocker les messages entrants dans le job existant, et a passé les messages récents dans l'invite OpenAI. Comme le reste de l'application était déjà structuré de manière assez standard dans Laravel, cela s'est intégré naturellement. Il n'y a pas eu beaucoup d'allers-retours ou de débogage.

C'est l'un des domaines où la structure antérieure a porté ses fruits. Une fois que la forme de l'application est solide, les agents ont tendance à être très doués pour l'étendre de manière prévisible.

"Travailler n'était pas vraiment travailler

Après la mise en œuvre initiale, la fonction a semblé fonctionner. L'In-App Messaging a répondu aux messages. Elle faisait référence au contexte précédent. On avait l'impression que la mémoire était en place.

Mais un rapide test en conditions réelles a révélé le problème : l'assistant ne se souvenait pas correctement de la conversation. Le système n'était pas totalement défaillant. Il se comportait de manière incohérente. Il s'agissait d'un type de bogue différent des phases précédentes.

Example of inconsistent conversation memory: the assistant initially references prior context (user name), but fails to connect follow-up messages about Tel Aviv and May.

Le bug le plus subtil : la mémoire incomplète

Lorsque l'agent a examiné ce qui était réellement stocké, le problème est apparu clairement. Seuls les messages des utilisateurs étaient enregistrés. Les réponses des assistants ne l'étaient pas.

L'historique des conversations au moment de la création de l'OpenAI ressemblait donc à ceci :

User: I want to plan a trip to Tel Aviv 
User: Can you help me plan this trip in May?

Du point de vue du modèle, il n'y a pas eu de conversation. Il n'y a aucune trace de la réponse de l'assistant, et il n'a donc rien sur quoi s'appuyer. Imaginez que vous essayez d'avoir une conversation mais que vous n'entendez que la moitié de ce qui est dit !

Au lieu de tout traiter comme un seul flux de messages, le système devait suivre les deux parties de manière explicite. L'agent a mis à jour la structure pour stocker à la fois les entrées de l'utilisateur et les réponses de l'assistant, reconstruire la conversation sous forme de tours alternés, puis transmettre les derniers tours à OpenAI.

Une fois que cela a été mis en place, le comportement s'est aligné sur les attentes. Les questions de suivi ont commencé à prendre tout leur sens car le modèle pouvait voir l'échange précédent.

Un point de défaillance de plus : Tests et migrations

C'est aussi la première fois que la persistance a commencé à affecter la suite de tests. Tout fonctionnait localement, mais les tests ont immédiatement commencé à échouer avec :

SQLSTATE[HY000]: no such table: conversations

Ce n'était pas un problème avec l'application. La base de données de test n'avait tout simplement pas la nouvelle table. Les migrations n'étaient pas exécutées dans le cadre de la configuration du test. Un développeur Laravel connaîtrait la solution : utiliser RefreshDatabase pour que les migrations soient exécutées dans les tests et que les charges utiles des tests soient mises à jour pour inclure tous les champs requis, tels que from.

Une fois ce dispositif mis en place, les tests ont de nouveau été concluants.

Phase 4 : Messages structurés (MCP devient obligatoire)

Voir : fourth_todo.md pour les tâches de l'agent.

À ce stade, l'application pouvait envoyer et recevoir des messages de manière fiable. Mais uniquement des messages texte. L'étape finale consistait à exploiter tout le potentiel de WhatsApp et à créer quelque chose de cool en y ajoutant :

• boutons de réponse

• listes interactives

Cela semblait être une petite extension, mais elle s'est avérée être la partie du projet la plus lourde en termes d'intégration.

Charge utile plausible rejetée par WhatsApp

La première tentative a semblé fonctionner. OpenAI renvoyait des réponses structurées comme :

{
 "type": "list",
 "content": {
   "items": [...]
 }
}

Du côté de Laravel, tout semblait correct : 1) la réponse OpenAI est revenue dans le format attendu, 2) le job s'est exécuté, et 3) le service Vonage a été appelé.

Mais la dernière étape a échoué :

Invalid params: The value of one or more parameters is invalid.

Ou parfois, ce qui est plus déroutant, rien n'apparaissait du tout dans WhatsApp. Du point de vue de Laravel, tout fonctionnait. L'API n'était pas d'accord.

Laravel logs showing a WhatsApp list message flowing through OpenAI and Vonage correctly, but failing at the final step with an “Invalid params” error due to a malformed interactive payload.L'agent a réagi comme il l'avait fait lors des phases précédentes. Il a essayé de remodeler la charge utile, d'ajuster les formats et même de revenir au texte brut pour faire passer quelque chose. Techniquement, cela a fonctionné, mais cela a permis d'éviter le vrai problème.

Les messages interactifs de WhatsApp ne sont pas de simples textes structurés. Ils doivent suivre des schémas stricts, et de petites déviations les rendent invalides. L'agent ne disposait pas d'un modèle fiable de ces contraintes, si bien qu'il continuait à générer des charges utiles qui semblaient raisonnables mais qui n'étaient pas acceptées.

Inadéquation des messages : SDK et réalité

Après quelques itérations, une autre erreur est apparue :

Argument #1 ($message) must be of type BaseMessage, array given

Le SDK de Vonage attend des objets de message typés, alors que les messages interactifs nécessitent un JSON profondément imbriqué. L'agent a transmis des tableaux correspondant à la forme de la charge utile, mais le SDK les a rejetés.

À ce stade, le problème n'était pas seulement la charge utile, mais aussi la couche par laquelle nous essayions de l'envoyer.

Deuxième tour : Forcer la documentation via MCP

C'est là que l'outil MCP de documentation de Vonage est redevenu essentiel.

Au lieu de continuer à remodeler les charges utiles, j'ai poussé l'agent à inspecter les schémas des messages WhatsApp et à travailler à partir de là.

L'approche a changé assez rapidement :

• utiliser le SDK là où il est utile (authentification, client de base)

• envoyer des messages interactifs via HTTP brut

• construire des charges utiles qui correspondent exactement à la structure documentée

Une fois que l'agent a eu le schéma sous les yeux, il a réussi.

Using the Vonage documentation MCP tool to confirm the correct SDK-based approach before refactoring the integration.

Conclusion

Deux jours auparavant, je n'aurais pas choisi Laravel pour autre chose qu'un tutoriel. À la fin, j'avais un concierge de voyage WhatsApp fonctionnel avec OpenAI, une mémoire de conversation et une messagerie structurée. Mais plus que l'application, c'est la compréhension du fonctionnement de cette méthode de construction qui est importante.

L'agent a été utile, mais pas autonome. Il a bien géré les échafaudages et les extensions, en particulier une fois la structure en place. C'est aux limites (flux de données, authentification, API strictes) qu'il a éprouvé des difficultés, car "presque correct" n'est pas suffisant.

Ce qui a fait la différence, c'est le flux de travail. En divisant le travail en phases, en imposant des tests précoces et en utilisant des outils MCP pour ancrer l'agent dans la documentation réelle, j'ai pu faire fonctionner rapidement des fonctionnalités compliquées. Sans cela, l'agent avait tendance à deviner. Avec le bon flux de travail, cela m'a permis de construire une application dont je ne peux pas expliquer la syntaxe.

Prochaines étapes

À partir de là, il est possible d'étendre l'application. Vous pouvez ajouter de nouveaux types de messages WhatsApp, comme les messages de localisation, pour indiquer aux utilisateurs où se trouvent exactement les lieux de leur itinéraire, ou utiliser les messages de fichiers pour générer et envoyer une version PDF d'un plan de voyage. Ce type d'ajouts permet d'aller plus loin dans l'intégration et souligne l'importance des API structurées et des flux de données clairs.

La conclusion est assez simple : vous pouvez vous déplacer dans des piles inconnues beaucoup plus rapidement avec un agent, mais seulement si vous gardez le contrôle de la structure et des limites. Si vous souhaitez explorer l'ensemble du projet, y compris le flux de travail par étapes, le code complet est disponible dans le dépôt dépôt GitHub.