Audit lucide, recommandations actionnables.

Quand faire appel à un consultant technique externe

Plusieurs points de bascule reviennent systématiquement dans les missions d'audit technique web suisse que nous menons. Le premier : un MVP qui plafonne. Les utilisateurs stagnent malgré l'acquisition payante, les temps de réponse se dégradent au fil des semaines, la dette technique freine chaque nouvelle release. L'équipe interne sent qu'il y a un problème mais ne sait plus distinguer une cause racine d'un symptôme. Le second : un bug en production récurrent qu'aucun développeur de l'équipe n'arrive à localiser, parfois depuis plusieurs mois. Logs incomplets, monitoring partiel, reproduction impossible en local — le ticket reste ouvert et les utilisateurs s'agacent.

Le troisième point de bascule est le choix de stack pour un nouveau projet. L'équipe interne hésite entre Next.js, Remix et Laravel, ou entre React Native et Flutter pour la version mobile. Chaque développeur défend sa préférence, le débat tourne en rond, et la décision est repoussée de semaine en semaine. Le quatrième : une levée de fonds avec due diligence technique imminente. Les fonds (Serpentine, Wingman, Redalpine, parfois des fonds européens plus larges) mandatent quasi systématiquement un audit indépendant avant de signer une série A. Mieux vaut anticiper que découvrir les findings critiques en pleine due diligence.

Le cinquième cas est la refonte qui s'éternise — six mois prévus, douze mois plus tard l'équipe livre encore par à-coups, le scope a dérivé, les budgets ont doublé. Dans tous ces cas, le rôle d'un consultant externe n'est pas de prendre la place de l'équipe interne. Il est de poser les bonnes questions, identifier les vraies causes (techniques, organisationnelles, ou les deux), et recommander un plan d'action chiffré que l'équipe peut exécuter. Un avis externe pèse différemment d'un avis interne : il n'a pas d'historique politique, pas de préférence d'outil à défendre, pas de carrière à protéger.

Audit technique : périmètre et livrables

Un audit code suisse romande complet couvre trois axes complémentaires. L'architecture d'abord : séparation des couches (présentation, métier, données), choix de la base de données et du modèle relationnel, patterns API (REST, GraphQL, tRPC, événements), scalability horizontale et verticale, points de single failure, stratégie de déploiement. Nous produisons des diagrammes C4 ou des schémas de flux qui rendent l'architecture explicite — souvent pour la première fois depuis le démarrage du projet.

La qualité du code ensuite : typage TypeScript strict ou relâché, couverture et pertinence des tests unitaires et d'intégration, structure des modules, conventions de nommage, code smells récurrents (duplications, complexité cyclomatique élevée, fonctions de plus de 100 lignes, couplage fort entre modules). Nous lisons effectivement le code — pas un échantillon de cinq fichiers — et nous documentons les patterns problématiques avec des références précises de fichiers et de lignes.

L'infrastructure enfin : pipeline CI/CD, monitoring applicatif (Sentry, Datadog, New Relic), monitoring infra (Grafana, CloudWatch), sauvegardes vérifiées par restore tests, sécurité opérationnelle (rotation des secrets, gestion des accès, audit des permissions IAM), observabilité (logs structurés, traces distribuées, métriques métier). Beaucoup d'équipes ont un monitoring théorique qui ne déclenche jamais d'alerte parce que les seuils sont mal calibrés.

Méthode : 1 à 3 semaines selon scope, accès en lecture au repository, deux à trois entretiens d'une heure avec l'équipe technique (tech lead, développeurs seniors, ops), accès en lecture aux logs production et aux dashboards. Le livrable est un document de 20 à 50 pages structuré en findings priorisés (P0 critique à corriger immédiatement, P1 important sous 30 jours, P2 souhaitable au prochain trimestre), chiffrage de chaque correctif en heures et en coût, roadmap d'exécution proposée. Pas de slides 80 pages décoratives : un PDF actionnable que les développeurs peuvent ouvrir et exécuter le lendemain.

Audit de performance et de sécurité

L'audit de performance commence par une mesure objective. Lighthouse et PageSpeed Insights sur les pages critiques (home, listing, fiche produit, checkout, dashboard authentifié), profiling Chrome DevTools sur les parcours utilisateurs réels, Sentry Performance pour identifier les transactions lentes côté serveur, analyse du bundle size avec @next/bundle-analyzer ou source-map-explorer. Nous identifions les bottlenecks classiques : queries SQL N+1 non détectées, images servies en JPEG non optimisé sans CDN, JavaScript bloquant le rendu (scripts tiers chargés synchronement), absence de cache HTTP côté edge, fonts custom non préchargés.

L'audit sécurité application web suisse suit le référentiel OWASP Top 10 : injection (SQL, NoSQL, LDAP, command injection), broken authentication, sensitive data exposure, XML external entities, broken access control, security misconfiguration, XSS, insecure deserialization, vulnérabilités de composants connus, logging insuffisant. Chaque catégorie est testée selon des scénarios précis. Scan des dépendances avec Snyk et Dependabot, recensement des CVE actifs sur les versions installées, review des flows OAuth et JWT (validation des claims, expiration, rotation des refresh tokens), gestion des secrets (variables d'environnement, AWS Secrets Manager, GCP Secret Manager, jamais en dur dans le repo).

Les couches souvent négligées : rate limiting sur les endpoints sensibles (login, reset password, API publique), headers HTTP de sécurité (Content-Security-Policy strict, HSTS avec preload, X-Frame-Options, Referrer-Policy, Permissions-Policy), cookies (HttpOnly, Secure, SameSite). Nous produisons un rapport priorisé avec exemples concrets de payload pour chaque vulnérabilité identifiée — pas une liste générique copiée d'un check-up automatique.

Choix de stack pour un nouveau projet

Le consulting next.js suisse représente une partie significative de nos missions, mais le choix de stack ne se réduit pas à un framework unique. Nous déclinons selon le contexte. Pour une startup early-stage avec un produit B2B web, le default est Next.js + Postgres avec Prisma + Vercel : productivité maximale (App Router, Server Components, Server Actions), écosystème mature, scaling automatique jusqu'aux dizaines de milliers d'utilisateurs sans intervention. Pour une application mobile native, React Native + Expo couvre 90% des cas avec un seul codebase iOS/Android.

Pour une application data-heavy ou un pipeline ML (ingestion, transformation, scoring, ranking), Python FastAPI ou Node.js avec des queues BullMQ ou AWS SQS gèrent la charge asynchrone proprement. Pour un site éditorial ou marketing, Next.js + Sanity headless reste imbattable sur le couple performance / DX éditorial. Les critères de choix que nous appliquons systématiquement : équipe disponible (le marché du recrutement Suisse romande favorise React et Node, plus difficile sur Elixir ou Rust), contraintes de scaling anticipées (combien d'utilisateurs à 6 mois, 2 ans, 5 ans), maturité de l'écosystème (libraries, hire pool, communauté active), contraintes de compliance (FINMA pour le secteur financier, RGPD européen, nLPD suisse depuis septembre 2023).

Les anti-patterns que nous voyons régulièrement et que nous déconseillons sans détour : Drupal pour un SaaS — conçu pour l'éditorial complexe, pas pour des workflows applicatifs ; Laravel monolithique pour une application temps réel avec milliers de connexions WebSocket simultanées ; Bubble ou autre no-code pour un produit avec logique métier custom complexe — la promesse initiale tient 6 mois, le mur arrive vers la deuxième année avec un coût de migration prohibitif. Nous expliquons pourquoi factuellement, avec des exemples chiffrés tirés de missions passées.

CTO fractionné : modalités

Une mission de cto fractionné genève s'organise typiquement sur 1 à 3 jours par semaine, avec une mission cadrée de 3 à 12 mois renouvelable. Le rythme inclut un point hebdomadaire avec le founder ou le COO, et une présence régulière dans les rituels d'équipe (daily, sprint review, retro selon la cadence). L'engagement va au-delà du conseil ponctuel : accompagnement du recrutement technique (rédaction des job descriptions, conduite des entretiens techniques, négociation salariale en lien avec les benchmarks suisses), code review systématique sur les pull requests critiques, décisions d'architecture validées en bilatéral avec le tech lead interne.

La présence aux comités stratégiques est incluse : board meetings quand des sujets tech sont à l'ordre du jour, due diligence technique côté entreprise (réponse aux questionnaires investisseurs), partenariats techniques (négociation avec un éditeur SaaS, intégration avec un partenaire data, choix d'un hébergeur). Le CTO fractionné fait le pont entre la vision business du founder et l'exécution technique de l'équipe — un rôle que ni un développeur senior ni un consultant ponctuel ne peuvent occuper seuls.

• Code review critique et architecture decisions sur les PRs structurants
• Rédaction de job descriptions techniques et conduite d'interviews
• Choix de stack et pilotage des migrations technologiques
• Sécurité, RGPD, nLPD et due diligence technique
• Liaison avec board et investisseurs sur les sujets tech
• Coaching du tech lead interne et montée en compétences

Reprise d'un projet existant après départ d'une équipe

La reprise d'un projet après le départ d'une équipe technique (freelances qui terminent, agence qui ne renouvelle pas, salarié qui part) suit un protocole en trois phases. Phase 1 cartographie, 1 à 2 semaines : récupération des accès complets (GitHub, Vercel, AWS, base de données, services tiers, domaines, certificats), inventaire de l'existant, identification des trous habituels (mots de passe partagés sans gestionnaire, services tiers actifs sans propriétaire identifié, infrastructure non documentée, scripts de déploiement uniquement dans la tête de l'ancien dev).

Phase 2 stabilisation, 2 à 4 semaines : corrections critiques sur les bugs bloquants identifiés, mise en place du monitoring si absent (Sentry au minimum), vérification effective des sauvegardes par un test de restore complet (la sauvegarde qui n'a jamais été testée n'est pas une sauvegarde), rotation des secrets sensibles, inventaire des CVE ouvertes sur les dépendances. Phase 3 refacto progressif sans freeze produit : réécriture par modules avec tests progressifs, déploiement continu maintenu, communication régulière aux stakeholders sur l'avancement.

Le coût typique varie selon l'état initial : 8 à 15k CHF si le projet est propre mais non documenté, 15 à 30k CHF si la dette technique est forte (versions de framework obsolètes, monitoring inexistant, sauvegardes douteuses, secrets hardcodés). La différence par rapport à une reprise par un freelance random : nous documentons systématiquement, nous testons effectivement, et nous ne réinventons pas tout sous prétexte que le code existant n'est pas à notre goût. Conserver ce qui fonctionne, corriger ce qui pose problème, refactorer ce qui freine — dans cet ordre.

Quand choisir une agence vs un studio dev

Le marché du conseil technique en Suisse romande propose plusieurs formats. Les cabinets conseil business + IT ont leurs forces : expertise sur la stratégie organisationnelle, gouvernance, transformation digitale d'entreprise, livrables très formels (slides structurés, matrices RACI, roadmaps haut niveau). Pour une transformation grande entreprise avec plusieurs départements impactés et un comité de pilotage formel, ce format reste pertinent.

Les cabinets tech suisses ont également leurs forces : équipes pluridisciplinaires, livrables concrets, intervenants seniors, organisation structurée en agence avec chargé de compte et chef de projet. Pour un audit avec compliance formelle ou une mission qui demande la mobilisation simultanée de plusieurs intervenants techniques, le format est cohérent.

Un studio dev comme fastdigital a un format différent : 1 à 2 intervenants seniors qui exécutent eux-mêmes la mission, échanges directs sans intermédiaires, livrable concret en PDF actionnable. Pour un audit ciblé d'une équipe de 5 à 20 développeurs, une due diligence technique avant levée, ou un choix de stack pour un nouveau projet, le format est souvent mieux adapté au besoin réel.

Le résultat technique est équivalent côté livrable — sur des audits purement techniques, le rapport est équivalent à scope égal. Format différent, coût plus accessible, qualité comparable. Pour un audit formel exigé par la compliance d'un grand groupe ou pour une transformation organisationnelle massive, les cabinets traditionnels restent pertinents. Pour la majorité des cas — startup, scale-up, PME tech — le format studio est plus adapté.

FAQ technique