Ajouter comme source préférée sur Google
Vous êtes prêt à tester une mise à jour d’une extension WooCommerce. L’IA vous aide à parcourir les notes de mise à jour, et vous avez ouvert un projet de plan de test. C’est alors qu’un collègue vous demande si la mise à jour affecte certaines règles de paiement personnalisées. Vous savez que quelques boutiques de clients en disposent. Mais lesquelles, exactement ?
Vous posez la question sur Slack. Le développeur qui connait ces sites est en réunion jusqu’à midi ; vous en profitez donc pour traiter un autre ticket en attendant.
Une autre agence utilise le même outil d’IA, mais son développeur peut repérer les exceptions de paiement dans les notes de chaque boutique. Une commande test est disponible, avec la remise attendue indiquée à côté. Il peut donc se mettre au travail.
À mesure que l’IA réduit le temps que vous consacrez à la préparation des modifications, ces détails quotidiens ont une influence croissante sur votre volume de travail accompli. Nous verrons comment rendre les connaissances de votre équipe sur les sites plus faciles à exploiter et comment fournir aux développeurs les éléments dont ils ont besoin pour évaluer les suggestions de l’IA. Nous aborderons également la manière de déterminer si ces améliorations permettent de gagner du temps sur l’ensemble de votre portefeuille de clients.
Quand le travail commence à s’accumuler
Grâce à l’IA, vous terminez un correctif en vingt minutes et l’envoyez pour validation. Votre responsable technique doit vérifier si cette même personnalisation fonctionne sur le site d’un autre client, mais il ne pourra s’en occuper qu’à partir de jeudi. Vous continuez à travailler. Au moment où il ouvre ce premier ticket, quatre autres correctifs l’attendent déjà.
Le problème est visible dans les horodatages des tickets. La rédaction ne prend que quelques minutes, mais l’attente dure des jours. Souscrire à un autre abonnement à une IA ne change rien à ce délai.
Dans l’étude d’Atlassian sur l’expérience des développeurs en 2025, 50 % des développeurs déclarent perdre au moins dix heures par semaine en tâches non liées au codage, principalement en raison d’inefficacités organisationnelles. L’enquête porte sur 3500 développeurs et responsables répartis dans six pays. La recherche d’informations figure parmi les principales sources de perte de temps. Il s’agit là d’expériences rapportées, et non de relevés de temps mesurés, mais elles constituent un point de départ utile pour les agences souhaitant mener une enquête.
Un membre de votre équipe peut passer une partie de chaque revue à rechercher des liens vers le référentiel ou à rappeler à ses collègues quels sites partagent une personnalisation. Même une personne prête à effectuer un test immédiatement peut être contrainte d’attendre que ses collègues lui fournissent l’accès nécessaire.
Conserver ces détails dans le dossier du site et veiller à ce que les développeurs en charge de celui-ci disposent des droits d’accès nécessaires permet d’éviter cela. Un collègue devrait pouvoir trouver les instructions de test existantes et se mettre immédiatement au travail. Le responsable peut toujours intervenir lorsqu’une modification se comporte de manière inattendue, sans avoir à répondre à chaque fois à la question « Où se trouve le code ? ».
Les connaissances sur le site conservées par votre équipe gagnent en valeur
Le point de terminaison de tarification personnalisé d’une boutique de vente en gros met plusieurs secondes à répondre. Lorsqu’on lui demande comment l’accélérer, un assistant IA suggère de mettre la réponse en cache pendant dix minutes. Cela éviterait au site de calculer un prix à chaque requête.
Or, chaque client bénéficie d’un tarif négocié. Si une réponse mise en cache est servie au mauvais compte, un acheteur pourrait alors consulter les tarifs d’une autre entreprise. Le développeur qui a écrit ce point de terminaison sait pourquoi celui-ci contourne le cache partagé. Une personne chargée d’un ticket de performance six mois plus tard pourrait y voir une opportunité d’accélérer le site sans se rendre compte des risques que cette modification fait courir.
Le commentaire à côté du point de terminaison peut bien sûr être simple. Une formulation telle que « Chaque compte grossiste dispose de son propre tarif négocié. Ne placez pas cette réponse dans le cache partagé » conviendrait parfaitement.
Dans la fiche du site, indiquez à vos collègues où se trouve le code et identifiez deux comptes de test avec des tarifs différents. Après une modification, ils pourront se connecter avec chacun de ces comptes et comparer le prix affiché avec le tarif dont l’acheteur devrait bénéficier.
Cela donne à votre collègue une raison de remettre en question une modification proposée concernant la mise en cache WordPress. Cela fournit également à un assistant IA un contexte plus utile lorsque vous lui demandez d’examiner des alternatives.
Réfléchissez à ce que vous mentionneriez en confiant un site à un collègue :
- « Le service des achats utilise ce rapport lors de la réunion de lundi. Il doit être prêt avant cette date. »
- « Les dates de l’importation sont exprimées selon le fuseau horaire du fournisseur. »
- « Nous attendons la résolution de ce problème d’extension avant de supprimer la solution de contournement. » Ajoutez le lien vers le ticket.
Lorsqu’une mise à jour de l’extension résout le problème, vous devez le noter et ajouter la date. Les anciennes instructions peuvent rester en place, et un résumé généré par l’IA peut continuer à recommander une solution de contournement dont votre site n’a plus besoin.
Utilisez l’outil d’IA approuvé par votre agence et supprimez les identifiants de tout ce que vous y collez. Les informations client peuvent généralement être omises elles aussi ; n’incluez-les que si la question les requiert. Ajoutez un lien vers le code ou les réglages concernés à côté de la réponse afin que le prochain développeur puisse vérifier s’ils correspondent à ce qui se trouve sur le site.
De bons diagnostics permettent aux développeurs d’évaluer plus rapidement les suggestions de l’IA
« Le processus de commande semble parfois lent » laisse une grande marge à la conjecture. Un assistant IA peut immédiatement générer une liste plausible de causes. Des diagnostics utiles vous permettent de commencer à les éliminer.
Les petites commandes s’effectuent sans encombre. En revanche, lorsque vous ajoutez douze produits différents au panier, le recalcul du montant total prend six secondes. Une trace de surveillance des performances de l’application met en évidence la fonction de remise personnalisée. Pour chaque ligne du panier, celle-ci interroge à nouveau la base de données et récupère une nouvelle fois l’historique des commandes du même acheteur.
Vous vous posez désormais une question précise : cette fonction peut-elle récupérer cet historique une seule fois et le réutiliser au cours du même calcul ? Vous pouvez demander à l’IA de vous aider à inspecter le code en tenant compte de cette contrainte.
Après avoir apporté la modification dans l’environnement de staging, répétez le test avec les douze produits et vérifiez le nombre de requêtes. Assurez-vous que la remise reste correcte lorsque vous modifiez les quantités. Un temps de réponse plus court n’a guère d’intérêt si le client reçoit un montant total erroné.
Si un autre membre de l’équipe se charge de l’analyse du processus de commande le lendemain matin, il disposera de la trace, mais saura-t-il que vous avez effectué le test en environnement de staging avec un compte grossiste ? Vous devrez indiquer ce détail dans le ticket. Pour les journaux d’erreurs WordPress, précisez-leur la plage horaire et le fuseau horaire correspondants afin qu’ils puissent retrouver les entrées issues du même test.
Cela importe également lorsque l’IA participe à l’analyse. L’étude « State of Observability 2025 » de Splunk, menée auprès de 1855 professionnels de l’observabilité, révèle que 48 % d’entre eux identifient la mauvaise qualité des données comme leur principal obstacle à la préparation à l’IA. Omettre de préciser quel compte déclenche la règle de remise réduit les éléments dont dispose l’assistant, aussi détaillée que puisse paraitre la trace.
Cela améliore également la communication avec votre client. Vous pouvez expliquer que les paniers volumineux chargent de manière répétée le même historique de commande et décrire le test qui vérifie votre correction. Le client obtient ainsi une explication du retard, au lieu d’un simple message indiquant que vous essayez différentes solutions.
Des environnements cohérents rendent les améliorations utiles à l’ensemble du portefeuille
Une seule correction de performance peut vous faire gagner du temps sur plusieurs sites, à condition de savoir où chercher ailleurs.
Supposons qu’une extension de reporting recalcule les totaux des commandes d’une année toutes les quinze minutes. Le client n’ouvre ce rapport que pour une réunion hebdomadaire. Vous constatez que ces recombinaisons répétées mobilisent du temps de la base de données et modifiez la planification pour l’adapter à la façon dont le client utilise le rapport.
Votre agence installe la même extension sur onze autres boutiques en ligne. Grâce à un inventaire à jour, vous pouvez les identifier et vérifier leurs réglages. Sans cela, quelqu’un doit ouvrir les tableaux de bord un par un ou rechercher le nom de l’extension dans les factures.
La question « Où ce site stocke-t-il son code personnalisé ? » devient vite lassante lorsque vous gérez plusieurs sites WordPress. Des emplacements de fichiers bien connus évitent à un collègue de devoir chercher, tout comme les notes qui utilisent le même nom pour un même réglage. Les notes de planification peuvent répondre à des questions auxquelles les réglages de l’extension ne répondent pas, par exemple si le serveur déclenche les tâches cron de WordPress.
La mention « Le personnel consulte ce rapport tout au long de la journée » doit figurer à côté du réglage d’actualisation dans les notes du site. Copier le planning hebdomadaire d’une autre boutique les amènerait à travailler à partir de chiffres obsolètes. Indiquez également la version de l’extension installée dans cette note. Un développeur peut perdre du temps à rechercher un réglage de planification qui existe dans une version plus récente mais qui n’apparait nulle part dans les réglages de cette boutique.
L’IA peut aider à comparer les réglages exportés ou à établir une liste de correspondances probables. Vérifiez cette liste par rapport aux sites réels avant d’appliquer la modification. La simple correspondance des noms d’extension ne prouve pas que les clients utilisent la fonctionnalité de la même manière.
Ajoutez la question « À quelle fréquence le client utilise-t-il ce rapport ? » aux notes de configuration de l’extension. Le développeur chargé de l’installer sur la boutique suivante pourra ainsi définir la planification dès la mise en service. Un rapport que le client ouvre le lundi matin n’a guère besoin d’être généré toutes les quinze minutes pendant toute la semaine. Votre équipe a déjà examiné ce problème une fois ; la prochaine installation bénéficiera de cette réponse.
Intégrez l’IA aux revues que vous effectuez déjà
L’examen des extensions du mardi peut impliquer de passer beaucoup de temps devant les journaux de modifications. Pour chaque site, quelqu’un doit comparer la version installée à la nouvelle version et déterminer quelles modifications méritent un examen plus approfondi. Par exemple, une boutique disposant d’une règle de remise personnalisée nécessite une attention particulière pour tout ce qui modifie la manière dont le processus de paiement calcule les prix.
Cela confère à un assistant IA une tâche spécifique. À partir de la version installée et d’une explication de la règle de remise, il peut identifier les modifications susceptibles d’affecter le calcul. Le résumé doit comporter des liens vers les notes de mise à jour, afin que votre développeur puisse lire ces entrées dans leur contexte. Il lui revient toujours de déterminer si une mise à jour affecte la boutique, mais il a moins d’informations à passer au crible au préalable.
« Vérifiez tous nos sites et indiquez-nous ce qui nécessite une attention particulière » lui donne beaucoup moins d’éléments sur lesquels travailler. Il peut produire un rapport d’apparence impressionnante qui omet le seul détail de compatibilité dont votre développeur a besoin.
Essayez cette tâche plus ciblée sur quelques sites que vous connaissez bien. Comparez le résultat avec votre propre analyse. Distingue-t-il une correction proposée d’une correction déjà publiée ? Traite-t-il un numéro de version manquant comme inconnu, ou comble-t-il cette lacune par une estimation ?
Le script compare la version du plugin installé sur chaque site avec la version disponible. Il signale également les exportations de configuration manquantes.
Lorsqu’un site ne renvoie pas sa configuration, le rapport indique : « Vérification incomplète. L’exportation de configuration de ce site est manquante. » Cette entrée permet alors de maintenir le site sur la liste des tâches à effectuer du vérificateur. Une ligne vide pourrait facilement donner l’impression que le site a passé le contrôle avec succès.
Évaluez le gain de capacité
Un après-midi sans avalanche de messages du type « Où puis-je trouver cela ? » donne à votre responsable technique le temps nécessaire pour mener à bien le travail destiné au client. Vous pouvez constater les avantages bien avant de prendre en charge un nouveau compte.
Vos tickets de projet et de support peuvent indiquer si les retards que vous essayez de réduire diminuent réellement. En fonction de ce qui continue de ralentir le travail, vous pouvez suivre :
- Temps d’attente avant la mise en production : combien de temps une modification terminée reste-t-elle en attente avant que quelqu’un puisse la vérifier et la valider ?
- Temps d’investigation : combien de temps le développeur passe-t-il à déterminer la cause d’un problème signalé ?
- Tickets rouverts : à quelle fréquence le même symptôme réapparait-il après que l’équipe a marqué une correction comme terminée ?
- Heures de support imprévues : quelle part du temps alloué au projet est consacrée à des réparations inattendues ?
Prenons par exemple six tickets de maintenance comparables qui nécessitent chacun que le chef de projet recherche des détails de configuration. Une fois que vous aurez amélioré les registres du site, examinez les six tickets suivants qui vous parviendront. Si les membres de l’équipe parviennent à traiter cinq d’entre eux sans cette interruption et que les corrections tiennent, vous disposerez d’une preuve que ces notes sont utiles.
Lorsqu’une personne clôt un ticket et confie la suite de l’analyse à un collègue, l’équipe doit tout de même consacrer du temps à cette réparation. Les développeurs ont également tendance à sous-estimer les heures de support lorsqu’ils omettent de noter sur leurs feuilles de temps les interruptions de cinq minutes. Ces interruptions fragmentent néanmoins leur journée, qu’ils les consignent ou non.
Plusieurs semaines de tickets comparables vous fournissent une meilleure base pour juger si une amélioration est constatée. Le volume de tickets est ici déterminant. Une semaine calme laisse naturellement plus de place au travail sur les projets, indépendamment des modifications apportées à votre documentation ou à vos outils d’IA.
Votre responsable dispose désormais de deux après-midi pour les projets clients. Une semaine chargée en matière d’assistance vous permet de déterminer si vous pouvez compter sur ce temps. S’il termine le travail prévu sans en reporter la moitié à la semaine suivante, vous disposez d’une base plus solide pour accepter un nouveau client.
Une configuration d’hébergement que votre équipe connait
« Vérifiez les journaux » suppose que votre collègue sache où les trouver. Si chaque client utilise un hébergeur différent, il risque de passer la première partie d’un ticket d’assistance à chercher dans un tableau de bord qui ne lui est pas familier. Une configuration familière lui permet de se consacrer directement à l’analyse.
Kinsta regroupe ces tâches dans MyKinsta. Lorsqu’une boutique en ligne ralentit, un développeur peut activer Kinsta APM pendant la durée de l’analyse et examiner les transactions impliquant du PHP, des requêtes de base de données et des requêtes externes. Il peut également consulter les journaux disponibles du site depuis le tableau de bord.
Le développeur peut recréer ce panier lent contenant 12 produits sur un site de staging WordPress à l’aide d’un compte de test en gros. Il connait le montant de la remise, ce qui lui permet de vérifier le nouveau calcul sans toucher aux commandes en production. La comparaison des vitesses nécessite un peu plus de précaution. Si l’environnement de staging utilise des réglages de mise en cache différents ou dispose de moins de ressources que l’environnement de production, les temps de réponse ne permettront pas d’établir une comparaison fiable.
« Pouvez-vous me donner accès ? » ne devrait pas être le premier message que vous recevez lorsqu’un collègue assure le support. La gestion des utilisateurs de MyKinsta vous permet de leur accorder un accès au site de staging à l’avance, l’accès au site de production étant réservé à la personne chargée de déployer le correctif. Si ce collègue travaille régulièrement sur plusieurs sites de vos clients, vous pouvez lui attribuer un rôle au niveau de l’entreprise plutôt que de configurer l’accès pour chaque site séparément.
Lorsque plusieurs boutiques utilisent votre extension de réduction, les libellés de site facilitent la recherche de ces installations. Vous pouvez afficher le groupe lorsqu’un correctif doit être testé, puis consulter la fiche de projet de chaque boutique pour connaitre ses règles de tarification. Le libellé doit toutefois correspondre à ce qui figure réellement sur le site. Une boutique qui n’utilise plus l’extension ne devrait plus apparaitre dans cette liste.
Où investir en priorité
La mention « J’attends toujours l’accès à l’environnement de staging » peut figurer dans un ticket pendant une demi-journée, tandis qu’une correction du processus de commande attend d’être testée. Si ce commentaire revient régulièrement dans vos tickets récents, vous avez un problème spécifique à résoudre. Les développeurs en charge de ces boutiques ont besoin de comptes leur permettant d’effectuer leur travail sans attendre que le titulaire du compte se reconnecte.
Un membre de votre équipe qui tente de se connecter avec ses propres identifiants vous en dira plus qu’une simple liste d’autorisations attribuées. Il peut accéder au tableau de bord tout en n’ayant toujours pas accès à l’environnement dont il a besoin. Le fait de le découvrir entre deux tickets vous laisse le temps de régler le problème sans que le client ait à attendre.
« Effectuez le test habituel de la page de commande » suppose que votre collègue connait la boutique aussi bien que la personne qui rédige le code de remise. Il se peut qu’il n’ait aucune idée de quel compte donne droit aux tarifs de gros. Indiquer la référence de ce compte à côté d’un lien vers la règle de réduction lui évite d’attendre la réponse de l’auteur.
« Je suis connecté. Quel devrait être le montant total du panier ? » Un commentaire de ce type sur le ticket suivant montre où les membres de l’équipe ont encore besoin d’aide. Le montant attendu doit être indiqué à côté de la référence du compte lorsque vous répondez. Sinon, la personne qui s’occupera de la commande la semaine prochaine risque de vous poser la même question. Encore une fois.
Facilitez la prise en charge du prochain site
De retour dans les deux agences, les deux développeurs ont préparé dès 10 heures des ébauches de test générées par l’IA. L’équipe ayant documenté l’exception de commande peut mettre son ébauche en pratique. L’autre a encore besoin d’une réponse de la part d’une personne en réunion.
Ces petits avantages prennent toute leur valeur à mesure que l’IA aide votre équipe à préparer davantage de travail. Ils vous permettent d’exploiter ce travail supplémentaire sans avoir à adresser chaque question à la même personne.
Choisissez un retard récurrent et éliminez-le. Fournissez ensuite au développeur suivant suffisamment d’informations pour qu’il puisse tirer parti de cette correction. L’hébergement WordPress infogéré de Kinsta offre à votre équipe un environnement familier pour étudier et tester les modifications à mesure que votre portefeuille de clients s’élargit.
Carlo est un passionné de webdesign et de développement frontend. Il joue avec WordPress depuis plus de 10 ans, notamment en collaboration avec des universités et des établissements d'enseignement italiens et européens. Il a écrit des dizaines d'articles et de guides sur WordPress, publiés à la fois sur des sites web italiens et internationaux, ainsi que dans des magazines imprimés. Vous pouvez trouver Carlo sur X et LinkedIn.
