Questions fréquentes

Au sens strict du terme, nous sommes une ESN.

Cependant, à la différence de beaucoup de nos concurrents, nous ne sommes pas là pour vous mettre à disposition des développeurs. Nous construisons une équipe adaptée à votre projet, bien au-delà du développement seul, en incluant en son sein les parties prenantes concernées chez vous.

Vous n’achetez pas de la main-d’œuvre, mais une machine apprenante, organisée pour construire et faire évoluer votre produit dans un contexte contraint et changeant.

Chaque projet est unique. Nous travaillons ensemble à réfléchir à l’équipe adaptée à votre projet, en fonction des compétences nécessaires : design, architecture, développement backend, développement frontend, science de la donnée…

L’équipe découle des travaux d’avant-projet, et pas l’inverse.

Nous n’avons pas de format unique : nous cherchons avec vous celui qui convient le mieux à votre projet. Les plus courants :

• des missions courtes d’expertise, par exemple un audit ciblé sur les performances, la sécurité, l’UX ou la faisabilité ;
• des missions « commando » de quelques mois, pour partir d’une idée et mettre un produit sur le marché ;
• des missions au long cours, pour faire évoluer un produit ;
• des reprises de projet, pour remettre dans un état qui permet d’itérer vite et sereinement un produit laissé à l’abandon, ou dont la dette technique a dépassé ce que l’équipe peut absorber.

Dans tous les cas, nous avançons par itérations, sur un nombre de semaines et un format convenus ensemble. Pour un périmètre bien défini, un forfait est aussi possible.

Souvent, le meilleur moment est « le plus tôt possible ». Même si ce n’est pas pour démarrer des développements à échéance courte, avoir une discussion rapidement permet souvent d’affiner la démarche de transformation de l’idée en produit, et en parler tôt est souvent une bonne idée, même si le projet est encore vague. Évidemment, une discussion sur votre projet n’est pas un engagement à travailler avec nous par la suite, nous prenons simplement le pari qu’en investissant sur un accompagnement d’avant-projet, les projets que nous réalisons réellement par la suite sont dans de meilleures conditions pour réussir.

Cela dépend du projet. Nous nous focalisons sur certaines technologies, et nous ne prendrons pas de projet qui soit hors de nos domaines de compétences. En fonction de l’âge et de l’avancement du projet, nous vous proposerons une phase d’audit de l’existant pour pouvoir proposer une intervention.

Nous faisons toujours attention à ce que nos rapports d’audits soient actionnables. Vous pouvez à l’issue de cette phase de bilan choisir, ou non, de travailler avec nous.

Pour les produits que nous développons, nous pouvons gérer les environnements d’exécution. En revanche, nous ne faisons pas d’infogérance avec engagement de niveau de service (SLO/SLA) : nous ne sommes pas équipés pour garantir une intervention en quelques heures ouvrées. C’est le métier d’infogérants spécialisés. Si c’est une exigence pour vous, nous vous accompagnons pour travailler efficacement avec eux, en leur fournissant tous les outils nécessaires pour surveiller l’application. Si vous n’avez pas d’exigence contractuelle, nous pouvons aussi, et c’est souvent ce que nous faisons, suivre le niveau de service réellement constaté et intervenir quand un incident pose vraiment problème. Le bon choix dépend de vos enjeux et de votre budget.

Le code que nous développons vous appartient : nos contrats prévoient explicitement la cession des droits. Les dépôts, les accès et les outils du projet sont aussi les vôtres : nous ne créons aucune dépendance technique artificielle envers Makersquad. Si vous le souhaitez, nous pouvons aussi gérer ces outils et ces accès pour vous, sans qu’ils cessent d’être les vôtres.

Si vous décidez un jour d’internaliser le développement ou de changer de prestataire, la transition se fait sans obstacle : le code, la documentation et les environnements sont conçus pour être repris par n’importe quelle équipe compétente.

Notre mode de travail intègre des revues de code systématiques et de l’intégration continue dès le premier jour du projet. Le code est versionné et accessible en permanence.

Nous mettons en place plusieurs niveaux de tests automatisés (unitaires, fonctionnels, end-to-end) couplés à un pipeline de déploiement continu. Cette approche nous permet de détecter les régressions au plus tôt et de garantir une stabilité des coûts de maintenance dans la durée. Un code bien testé et bien structuré, c’est un code qui reste économique à faire évoluer.

Chaque projet commence par une phase d’avant-projet pour comprendre vos enjeux, identifier les contraintes et définir le périmètre. Cette étape permet de constituer l’équipe adaptée et de poser les bases techniques.

Ensuite, nous travaillons en itérations courtes (1 à 2 semaines) avec des démonstrations régulières. Chaque itération produit un incrément fonctionnel que vous pouvez tester et sur lequel vous donnez du feedback. Les choix techniques et fonctionnels sont discutés et argumentés au fil de l’eau, pas imposés en fin de projet.

Nous intervenons sur trois écosystèmes :

• Python : Django, FastAPI, Starlette, Flask, ou directement sur les standards ASGI et WSGI, sans framework ;
• JavaScript et TypeScript, en particulier React pour les interfaces ;
• le cloud et le DevOps : conteneurs, Kubernetes, infrastructure as code avec Terraform / OpenTofu.

Hors de notre domaine de compétence, nous vous orientons vers un autre prestataire : un partenaire de confiance si nous en connaissons un, sinon nous le cherchons avec vous.

Par les tests, systématiquement. Nous pratiquons le TDD (Test-Driven Development) : chaque fonctionnalité est d’abord spécifiée par un test avant d’être implémentée. Ce n’est pas un idéal théorique, c’est notre pratique quotidienne.

Concrètement, cela signifie que chaque livraison passe par une suite de tests automatisés (unitaires, d’intégration, et fonctionnels selon le contexte), une revue de code par un pair, et un pipeline CI/CD qui valide l’ensemble avant tout déploiement. Nous ajoutons à cela un monitoring en production (Sentry pour les erreurs, alerting sur les métriques clés) pour détecter rapidement ce que les tests ne couvrent pas.

Le résultat : des mises en production régulières et sereines, pas des déploiements à risque le vendredi soir.

Nous commençons par un audit des dépendances et des breaking changes entre la version actuelle et la version cible. Ensuite, nous procédons par étapes : mise à jour des dépendances tierces, adaptation du code applicatif, passage complet de la suite de tests. Chaque étape est validée avant de passer à la suivante.

La couverture de tests existante est déterminante. Si elle est insuffisante, nous renforçons les tests critiques avant de toucher aux versions. L’objectif est de garantir que le comportement métier reste identique après la migration, pas de tout casser pour être à jour.

Par défaut, nous recommandons Django avec PostgreSQL, et la stack la plus légère possible. Selon le projet, nous ajoutons par exemple Celery et Redis pour les tâches asynchrones, Django REST Framework ou Django Ninja pour les API, React ou une approche plus légère pour les interfaces. Côté outillage : pytest pour les tests, intégration et déploiement continus, Sentry pour le suivi des erreurs, Prometheus et Grafana pour le monitoring, Docker pour les environnements. Ce ne sont que des exemples : nous ne vendons pas une stack toute faite. Chaque élément est choisi avec soin, parce que chaque dépendance devra ensuite être maintenue, et que cela a un coût pour vous. Nous partons toujours de vos contraintes réelles : équipe en place, infrastructure, budget, délais.

Oui, nous intervenons aussi sur FastAPI, Starlette et Flask, et nous pouvons travailler directement sur les standards ASGI ou WSGI, sans framework, quand le projet le demande. Django reste notre recommandation par défaut pour les applications métier, mais certains contextes (microservices, API légères, traitement de données en temps réel) justifient d’autres choix.

Nous adaptons la stack au besoin, pas l’inverse. Et quand un projet combine plusieurs frameworks (par exemple Django pour le back-office et FastAPI pour une API haute performance), nous savons les faire cohabiter proprement.

Difficile de répondre dans l’absolu sans contexte. La plupart du temps, on parle de quelques semaines. On commence par un cadrage court pour clarifier l’hypothèse à tester et définir le périmètre minimal, puis on construit ce qu’il faut pour la valider.

La durée dépend du format retenu : une landing page avec métriques se met en place en quelques jours, un prototype interactif ou une application minimale prend plus de temps. L’objectif n’est pas de tout construire, mais de construire juste ce qu’il faut pour apprendre.

Non. C’est même souvent le bon moment. Le cadrage MVP sert justement à transformer une intuition en hypothèse testable. Pas besoin d’un cahier des charges complet pour démarrer.

On commence par identifier le problème que vous essayez de résoudre et pour qui. Nous avons des outils pour vous accompagner à structurer vos idées et identifier les hypothèses les plus risquées, celles à valider en priorité. Le flou initial est normal, c’est le processus de cadrage qui le dissipe.

C’est un résultat précieux, pas un échec. Apprendre tôt qu’une hypothèse est fausse évite des mois de développement inutile et un budget dépensé sur un produit que personne ne veut.

On analyse les données collectées pour comprendre pourquoi l’hypothèse n’a pas tenu. Ensuite, on décide ensemble : ajuster la proposition de valeur, pivoter vers un autre angle, ou arrêter. Chaque décision repose sur des données concrètes, pas sur des suppositions.

Pas de choix imposé : la technologie découle de ce qu’il faut tester et du contexte du projet. Pour une landing page de validation, pas besoin de développement sur mesure.

Pour une application, notre recommandation par défaut s’appuie sur nos trois écosystèmes : Python ; JavaScript et TypeScript, avec React, et React Native pour le mobile ; le cloud et le DevOps. Des outils no code ou low code suffisent parfois. Le critère principal est la vitesse d’apprentissage : mettre le produit entre les mains d’utilisateurs le plus vite possible, sans sacrifier la qualité de ce qui sera mesuré.

Un audit prend de quelques jours à quatre semaines selon son ampleur, le plus souvent de l’ordre d’une semaine. Performances, sécurité, interface, code, architecture, processus, produit : nous incluons ces aspects ou non selon les questions que vous vous posez. Nous décidons ensemble du périmètre, puis nous convenons d’un délai adapté, qui dépend aussi de la taille des bases de code et des équipes à rencontrer.

Ces rencontres avec vos équipes (techniques, opérationnelles, produit) sont indispensables pour comprendre le contexte et produire des recommandations pertinentes.

Oui, c’est un objectif explicite. Nous choisissons avec vous les axes de l’audit, et le rapport est conçu pour être actionnable directement, par vos équipes ou par un autre prestataire.

Chaque recommandation est priorisée, avec des repères sur sa taille, sa difficulté et son impact attendu. Plusieurs niveaux de lecture permettent à chacun d’y trouver ce dont il a besoin, selon son expertise et le temps qu’il peut y consacrer. Nous ne créons pas de dépendance : vous repartez avec un document clair, structuré et autonome.

Le rapport s’appuie sur une structure type, que nous adaptons à chaque projet :

• un executive summary, lisible en un coup d’œil par les décideurs ;
• le contexte : pourquoi l’audit, et les problématiques à traiter ;
• une analyse détaillée de chaque problématique, chiffrée et appuyée sur des mesures ;
• pour chacune, des recommandations priorisées selon l’effort et l’impact attendu.

Chaque audit est mené de bout en bout par un expert très expérimenté du développement web et logiciel, selon une méthodologie que nous avons affinée au fil des années chez Makersquad. Il s’appuie sur tout un outillage pour mesurer et analyser votre application selon ce qu’on cherche : débogueurs, profileurs, traces, outils du navigateur… et des agents IA, que nous utilisons beaucoup pour collecter de nombreuses informations en parallèle, ou pour en synthétiser un grand volume. Mais l’analyse, le jugement et les recommandations restent ceux de l’expert. C’est notre façon de penser l’IA chez Makersquad : quels que soient les outils, c’est la personne qui les utilise qui reste responsable du résultat.

Les deux. Nous pouvons intervenir uniquement sur la phase de conception (recherche utilisateur, wireframes, maquettes) et vous transmettre les livrables pour que vos développeurs les intègrent. Nous pouvons aussi assurer le suivi de l’implémentation avec les équipes techniques pour garantir que le produit final correspond aux intentions de design. Cette continuité réduit les pertes de traduction entre design et développement.

Oui. Nous partons de ce qui existe : maquettes Figma, charte graphique, design system ou simples règles en place, nous les exploitons et les faisons évoluer. L’analyse des parcours actuels et des points de friction, avec les retours de vos utilisateurs quand il y en a, nous permet de prioriser les améliorations à fort impact plutôt que de tout refaire.

S’il n’y a pas encore de cadre, nous en construisons un avec vous : pérenne et documenté, il pourra être repris et modifié par nous comme par d’autres.

L’UX (expérience utilisateur) désigne la conception des parcours et des interactions : comment l’utilisateur navigue, comprend et atteint ses objectifs. L’UI (interface utilisateur) désigne la conception visuelle : typographie, couleurs, composants, hiérarchie visuelle. Les deux sont indissociables : un bel écran sur un parcours mal pensé frustre autant qu’un parcours efficace mais illisible. Nous les traitons ensemble, dans une approche intégrée orientée usage.

Selon la nature et la phase de la mission, les livrables peuvent inclure : personas, cartes d’expérience, synthèses des entretiens utilisateurs, user flows, wireframes, maquettes haute fidélité, prototypes interactifs et design system. Tous les livrables sont conçus pour être utilisables en autonomie par vos équipes produit ou tech, que vous choisissiez ou non de continuer avec nous.

Nous choisissons les outils selon la mission et le projet : Figma pour les maquettes et les prototypes, le tableau blanc pour les ateliers, le téléphone et la visioconférence pour échanger avec les utilisateurs, Storybook pour documenter les composants, Claude Design et Claude Code pour passer plus vite au concret. Notre objectif : vous livrer un matériel directement exploitable, dans les outils que votre équipe utilise déjà.

Oui. Python étant particulièrement puissant pour l’automatisation, nous intervenons sur des scripts de traitement de données, d’intégration avec des services tiers, d’extraction et de transformation de données ou de synchronisation entre systèmes. Ces missions peuvent être ponctuelles ou intégrées à un projet plus large.

Nous maîtrisons principalement deux frameworks, complémentaires :

• Django, pour les applications métier qui doivent durer : stable depuis près de vingt ans, maintenu par une fondation et une équipe de sécurité actives, il offre une base très solide ;
• FastAPI, pour des API modernes, performantes et asynchrones : plus jeune, porté par une petite équipe, il évolue vite et apporte beaucoup de modernité.

Le choix dépend des besoins du projet : complexité métier, volume de requêtes, exigence de stabilité, type d’interface à exposer. Quand les contraintes l’exigent, nous pouvons aussi travailler directement sur les standards ASGI ou WSGI, sans framework.

Nous travaillons aussi bien sur le frontend React que sur le backend (Python, Node.js). Cette double compétence nous permet de concevoir des interfaces cohérentes avec les API, de gérer les contrats de données et d’éviter les frictions d’intégration courantes dans les projets segmentés.

Plusieurs techniques fiabilisent ce lien, comme les spécifications OpenAPI, les schémas JSON ou la génération automatique des types côté frontend. Le choix dépend de la situation : le rôle du backend, le nombre d’applications qui le consomment, l’équipe en place.

Oui. Nous intervenons sur des frontends existants pour améliorer la structure des composants, réduire la dette technique, migrer vers des versions récentes de React, ou optimiser les performances. Nous commençons toujours par analyser l’existant avant de proposer des modifications.

Nous nous appuyons aussi sur des outils à base d’agents IA, très efficaces pour mener rapidement des montées de version, y compris quand elles cassent la compatibilité. Le tout en sécurité : avant de toucher au code, nous posons un filet de tests qui vérifie que tout fonctionne toujours.

React excelle sur les applications web très dynamiques, à forte logique métier, parfois construites par plusieurs équipes autour d’une bibliothèque de composants réutilisables et fidèles à une charte : ce n’est pas un hasard s’il est né chez Facebook. Produits SaaS, tableaux de bord et back-offices en tirent pleinement parti.

En revanche, pour un site avant tout de contenu (blog, articles, pages pensées pour le référencement), React peut être contre-productif : nous vous proposerons alors des options mieux adaptées.

Cela dépend du projet. Pour la plupart des applications (produits SaaS, back-offices, outils métier), nous partons de React avec Vite : un outillage rapide, simple et peu prescriptif, qui laisse l’architecture s’adapter au projet. Pour un site avant tout de contenu, nous utilisons Astro : il produit des pages très légères et peut intégrer des composants React là où l’interactivité le demande. Next.js est un framework complet et répandu, mais aussi plus lourd et plus restrictif. Si votre projet repose dessus, nous pouvons bien sûr intervenir.

Oui. Nous travaillons avec TypeScript sur l’ensemble de la stack, côté frontend (React) comme côté backend (Node.js), avec la même compétence DevOps et la même approche cloud native que sur nos autres projets.

Le typage des API sécurise la communication entre frontend et backend, directement par les types TypeScript ou par un format intermédiaire comme JSON Schema, par exemple pour reprendre les types définis par une application Django ou FastAPI.

Selon le projet, nous pouvons aussi construire une application entièrement côté frontend, en nous appuyant sur un backend en tant que service, voire sans backend du tout : une option qui permet des économies importantes.

Le typage statique de TypeScript permet de détecter les erreurs dès l’écriture du code plutôt qu’en production. Il améliore la lisibilité, facilite la collaboration entre développeurs et réduit le coût des évolutions dans le temps.

La migration peut se faire progressivement, fichier par fichier, sans tout réécrire. Votre équipe découvre TypeScript sur du code qu’elle connaît déjà, à son rythme.

Oui. Nous menons ces migrations progressivement, fichier par fichier, sans arrêter le projet ni bloquer les évolutions en cours. Avant de toucher au code, nous posons un filet de tests qui vérifie que tout fonctionne toujours.

Nous définissons avec vous une stratégie adaptée au volume de code, à la criticité du projet et au rythme que votre équipe peut absorber. À chaque étape, l’application reste en service et le typage gagne du terrain.