Les meilleures agences de développement web à Bordeaux (octobre 2026)

Avant de comparer les agences du classement, décrivez les actions que votre futur site ou application doit rendre possibles. Un visiteur doit-il trouver une information, déposer une demande, gérer un compte ou suivre une commande ? Pour chaque parcours, précisez son point de départ, le résultat attendu et les difficultés observées aujourd’hui. Cette description donne une base commune aux échanges et évite de comparer des propositions qui répondent à des besoins différents.

Le Service Manual de GOV.UK consacré à la découverte recommande de comprendre le problème, les utilisateurs et les contraintes avant de décider de construire un service. Retenez ici cette précaution de cadrage : une solution annoncée doit pouvoir être discutée à partir du besoin auquel elle répond.

Préparez ensuite une note de périmètre. Séparez les fonctions nécessaires au lancement, celles qui peuvent attendre et les questions encore ouvertes. Mentionnez les contenus disponibles, les outils existants et les personnes capables de fournir les accès. Pour une reprise de site, indiquez aussi ce qui doit être conservé : adresses de pages, comptes, documents ou historique métier.

Terminez cette note par des critères observables. Au lieu de demander une interface intuitive, décrivez une tâche que l’utilisateur doit terminer et les obstacles à éviter. Demandez à chaque agence de reformuler le périmètre et de signaler ses hypothèses. Vous pourrez alors décider si vous cherchez une réalisation déjà définie ou un accompagnement préalable pour lever les incertitudes, avec un livrable de cadrage explicitement identifié.

La présence dans un classement consacré à Bordeaux ne suffit pas à établir une implantation dans la ville. Distinguez trois informations lors de votre sélection : le siège documenté, un éventuel bureau effectivement utilisé par l’équipe et une intervention déclarée sur des projets bordelais. Consignez séparément ces éléments, avec leur source et leur date de consultation, plutôt que de les réunir sous une étiquette locale imprécise.

Pour vérifier une adresse, rapprochez les mentions publiées par l’agence du document d’identification qu’elle vous communique. Demandez si cette adresse correspond au siège, à un espace de travail ou à un lieu de rendez-vous. Faites préciser quelle équipe y travaille et si une rencontre peut y être organisée. Une adresse seule ne renseigne ni sur l’équipe affectée à votre projet ni sur les conditions concrètes des échanges.

Définissez ensuite les moments où une présence physique vous serait utile : atelier avec plusieurs métiers, observation d’un usage sur place ou transmission aux administrateurs. Pour chacun, demandez qui participerait, où aurait lieu la séance et comment ses conclusions seraient conservées. Faites également préciser les modalités de déplacement proposées, sans supposer leur inclusion.

Comparez enfin cette organisation avec un fonctionnement distant décrit au même niveau de détail. Exigez un interlocuteur identifié, un espace partagé pour les décisions et une procédure de retour sur les démonstrations. Choisissez selon les besoins réels de votre équipe : la proximité géographique devient un critère vérifiable lorsqu’elle correspond à des échanges utiles et organisés, plutôt qu’à une simple mention de Bordeaux.

Une référence devient utile lorsque vous comprenez ce que l’agence a réellement réalisé. Demandez un exemple proche de votre difficulté principale : reprise de données, espace connecté, interface d’administration ou connexion à un outil métier. La ressemblance visuelle avec votre futur site compte moins que la possibilité de discuter des décisions techniques et des contraintes rencontrées sur ce travail précis.

Faites décrire le périmètre pris en charge. Qui a conçu les parcours, développé les interfaces, réalisé les connexions et assuré la mise en ligne ? Une agence peut avoir participé à un projet sans avoir produit tous ses éléments. Demandez quels documents ou éléments elle peut présenter pour expliquer sa contribution, dans les limites de ce qu’elle est autorisée à partager.

Préparez des questions concrètes pour cette présentation. Comment les erreurs de saisie étaient-elles traitées ? Que se passait-il lorsqu’un service externe ne répondait plus ? Comment l’équipe cliente pouvait-elle modifier ses contenus ? Demandez aussi quelle difficulté a entraîné une révision du périmètre. Ces échanges permettent de rapprocher une expérience présentée des situations que votre projet devra gérer.

Conservez une fiche par référence avec le contexte, la contribution déclarée, la preuve disponible et les points restant à confirmer. Lorsqu’un élément ne peut pas être montré, notez cette limite sans en déduire automatiquement une qualité ou une faiblesse. Au moment de choisir, privilégiez les éléments qui répondent à vos incertitudes. Un portfolio apporte des pistes de discussion ; il ne démontre pas, à lui seul, la capacité à couvrir votre besoin exact.

Deux propositions de développement peuvent employer les mêmes termes tout en prévoyant des résultats différents. Demandez pour chaque livrable son contenu, son format, son destinataire et le moment où il sera remis. Une maquette ne remplace pas une interface fonctionnelle ; une démonstration ne remplace pas la remise des éléments nécessaires à l’exploitation. Rendez ces distinctions visibles avant de choisir.

Le tableau suivant est une grille proposée par la rédaction. Il décrit des pièces à demander et des critères de lecture, sans attribuer ces prestations aux agences du classement.

Utilisez cette grille pendant une lecture commune de chaque proposition. Lorsqu’un intitulé reste vague, demandez un exemple de contenu attendu ou une description de sa structure. Faites préciser les éléments qui dépendent de vos propres contributions, notamment les textes, les traductions ou les accès aux services externes.

Consignez enfin les livrables absents et ceux présentés en option. Votre décision pourra porter sur un périmètre compris, avec des écarts explicités, sans confondre le nombre de documents annoncés avec leur utilité pour votre équipe opérationnelle.

Le choix technique doit pouvoir être expliqué à partir des usages et des contraintes du projet. Demandez à l’agence de présenter l’architecture envisagée : interface publique, administration, stockage des données et services externes. Faites identifier les fonctions portées par chaque élément. Cette représentation doit permettre à votre équipe de comprendre où une modification devra être réalisée et qui devra intervenir.

Discutez les arbitrages plutôt qu’une simple liste de technologies. Qui pourra publier un contenu ? Comment une nouvelle règle métier sera-t-elle ajoutée ? Quels éléments dépendent d’un abonnement ou d’un fournisseur extérieur ? Demandez quelles alternatives ont été envisagées et pourquoi elles ont été écartées. Une réponse utile relie chaque choix à une contrainte documentée, sans présenter une technologie comme adaptée à toutes les situations.

Établissez ensuite une matrice de responsabilités. Attribuez la création des comptes, la fourniture des accès, la configuration de l’hébergement, la gestion du domaine et la validation des données échangées. Pour chaque sujet, désignez la personne qui exécute, celle qui décide et celle qui doit être informée. Clarifiez aussi le rôle des prestataires déjà présents dans votre organisation.

Traitez enfin les dépendances avant de lancer les développements concernés. Si une connexion suppose une documentation ou un accès encore manquant, rendez cette attente visible et définissez la décision qu’elle bloque. Demandez comment le périmètre sera réexaminé si l’hypothèse initiale ne se confirme pas. Vous pourrez choisir une proposition dont les conditions de réalisation sont explicites et dont les responsabilités correspondent aux moyens de votre équipe.

Pour une refonte, la reprise de l’existant mérite une décision distincte du choix des nouveaux écrans. Dressez un inventaire des contenus, fichiers, comptes et données métier concernés. Indiquez pour chaque ensemble son emplacement, son responsable et sa destination envisagée. Séparez ce qui doit être conservé, transformé, archivé ou laissé hors du nouveau périmètre, avec une validation par la personne concernée.

Demandez une correspondance entre les informations actuelles et les champs du futur système. Cette correspondance doit faire apparaître les valeurs manquantes, les doublons et les formats incompatibles. Décidez qui corrige les données et à quel moment. Évitez de laisser cette responsabilité implicite : une agence ne peut pas arbitrer seule la signification d’un statut métier ou choisir quelle version d’un contenu fait référence.

Prévoyez une répétition de la reprise sur un environnement de préparation. Demandez un compte rendu qui distingue les éléments transférés, les éléments rejetés et ceux nécessitant une intervention. Faites examiner des exemples représentatifs par les personnes qui utilisent ces informations. Pour les pages publiques conservées ou déplacées, préparez également une correspondance entre anciennes et nouvelles adresses, puis définissez leur vérification.

Enfin, fixez la manière de traiter les modifications réalisées entre cette répétition et la mise en ligne. Faut-il interrompre certaines saisies, reprendre uniquement les changements ou refaire un transfert complet ? Faites documenter l’option retenue et la personne qui autorisera le passage. Cette préparation permet de décider si la reprise est suffisamment maîtrisée pour intégrer le lancement ou si elle exige un chantier préalable.

La validation doit porter sur des comportements décrits, accessibles à la discussion entre votre équipe et l’agence. Pour chaque parcours prioritaire, préparez un scénario avec une situation de départ, des actions et un résultat attendu. Ajoutez les conditions nécessaires : type de compte, contenu disponible ou réponse attendue d’un service externe. Vous saurez ainsi ce qui a été présenté et ce qui reste à examiner.

Incluez les situations qui sortent du déroulement idéal. Un champ obligatoire oublié, une recherche sans résultat, une session expirée ou une connexion interrompue appellent des réponses différentes. Demandez à voir les messages, les possibilités de correction et la conservation éventuelle des informations déjà saisies. Ces décisions concernent directement l’usage du développement livré et doivent apparaître dans les retours.

Préparez également les conditions d’accès à la validation. Définissez les navigateurs et appareils retenus pour votre projet, puis les parcours à examiner au clavier et sur un écran étroit. Faites participer les personnes qui administreront le site aux scénarios de création, de modification et de suppression de contenus. Une interface publique validée ne suffit pas à confirmer que l’administration répond aux besoins de publication.

Centralisez les observations avec une description reproductible, le résultat attendu et la décision prise. Distinguez anomalie, précision du besoin et nouvelle demande afin de décider de leur traitement. Désignez enfin la personne autorisée à accepter un parcours et les points qui empêcheraient sa validation. Vous disposerez d’un état partagé pour décider de poursuivre, de corriger ou de réexaminer le périmètre.

Transformez la sécurité en questions attribuées et documentées. Demandez quelles données entrent dans l’application, qui peut les consulter et quelles opérations chaque rôle peut effectuer. Faites décrire les accès d’administration, la suppression d’un accès devenu inutile et la séparation entre les environnements de préparation et de production. Chaque réponse doit correspondre au fonctionnement prévu de votre projet.

Le guide introductif de MDN sur la sécurité web explique notamment que les données reçues du navigateur doivent être contrôlées. Il présente les requêtes paramétrées contre les injections SQL, l’usage de HTTPS et l’importance des mises à jour. Ces repères servent à formuler des questions techniques ; ils ne constituent pas une garantie de sécurité.

Demandez ensuite une présentation des dispositions retenues pour les fonctions sensibles de votre application. Pour un dépôt de fichier, faites préciser les conditions d’acceptation et les droits de consultation. Pour un espace connecté, interrogez les comportements prévus lors d’un accès refusé ou d’un compte désactivé. Si une vérification spécialisée est proposée, demandez son périmètre, le document remis et la manière de suivre les corrections.

Préparez enfin une fiche de décision avant ouverture : points examinés, réserves connues, responsables et actions restantes. Les accès encore trop larges, les comptes provisoires et les données utilisées pendant la préparation doivent faire l’objet d’une revue explicite. Autorisez l’ouverture à partir d’éléments identifiés, en sachant qui devra traiter une alerte. Aucune formulation générale sur une application sécurisée ne remplace cette visibilité.

La mise en ligne doit être décrite comme une opération avec des prérequis et un responsable de décision. Demandez un plan indiquant les éléments à publier, les configurations à appliquer et les vérifications prévues après ouverture. Faites identifier les accès nécessaires et leur détenteur avant le lancement. Un accès manquant au domaine ou à l’hébergement ne devrait pas être découvert au moment de basculer.

Prévoyez une répétition sur l’environnement retenu pour la préparation, lorsque cela est possible dans votre organisation. Faites préciser les différences restantes avec la production : comptes, services externes, données ou paramètres. Demandez comment ces écarts seront contrôlés. La décision de publier doit tenir compte des limites connues de cette répétition, sans considérer une démonstration réussie comme une validation de toutes les conditions réelles.

Définissez les contrôles immédiatement utiles après ouverture. Ils peuvent concerner l’accès aux pages prioritaires, la connexion des utilisateurs, l’envoi des demandes et la disponibilité de l’administration, selon votre périmètre. Attribuez chaque contrôle à une personne et indiquez comment son résultat sera partagé. Si des opérations métier se poursuivent pendant la bascule, précisez comment leur continuité sera organisée.

Demandez enfin un scénario de retour arrière. Quels éléments pourraient être restaurés, qui en déciderait et comment seraient traitées les données créées depuis l’ouverture ? Faites expliciter les situations dans lesquelles ce retour serait incomplet ou inadapté. Vous pourrez autoriser le déploiement avec une compréhension concrète des actions prévues, des limites et des interlocuteurs mobilisables selon les modalités convenues pour cette opération.

La transmission doit permettre à votre équipe de comprendre ce qu’elle reçoit et comment le faire fonctionner. Demandez un inventaire de remise couvrant le code, les configurations, la documentation, les comptes et les services utilisés. Pour chaque élément, indiquez son emplacement, son responsable et la manière d’y accéder. Vérifiez que cette remise correspond à l’architecture finalement livrée, y compris ses dépendances externes.

Organisez une séance de prise en main à partir de tâches réelles. La personne chargée des contenus doit pouvoir publier, corriger et retirer une information dans le périmètre prévu. Le référent technique doit savoir retrouver les instructions de déploiement, les paramètres nécessaires et les informations utiles à une reprise. Demandez que les questions non résolues soient consignées avec une action attribuée.

Distinguez ensuite le traitement des anomalies, les opérations de maintenance et les évolutions fonctionnelles. Faites préciser le canal de demande, les informations à transmettre et la manière dont une intervention sera acceptée et suivie. Demandez qui surveille les services, qui examine les mises à jour et qui vérifie les sauvegardes selon l’organisation retenue. Ne supposez aucune disponibilité ni aucun délai sans engagement explicite dans la proposition.

Choisissez enfin quelques observations utiles au suivi : parcours terminés, erreurs rencontrées ou difficultés de publication, selon les moyens de mesure décidés. Associez chaque observation à une question et à une personne capable d’agir. Le bilan doit aider à décider entre correction, évolution ou maintien du fonctionnement actuel. Cette organisation donne une suite concrète au développement et prépare une éventuelle transmission à une autre équipe.