Beaucoup de dirigeants, au moment de décider de créer un site vitrine ou un système, ont pour premier réflexe de « demander d'abord un devis ». Résultat : après avoir consulté trois prestataires, les devis vont de 20 000 à 200 000, les propositions sont toutes très bien rédigées, et l'on ne sait finalement plus qui choisir.
Le problème n'est pas le prix, mais le fait que vous n'avez pas encore clarifié comment ce projet doit être mené et à quel stade il est considéré comme terminé. Le développement web n'est pas l'achat d'un produit standard : si le périmètre du projet est flou, les conflits surviendront à coup sûr par la suite.
Voici plusieurs points décomposés selon l'ordre réel d'avancement, pour vous aider à juger si le projet que vous avez en main se prête à une équipe externe, et comment le confier sans tomber dans les pièges.
Distinguer d'abord projet de présentation et projet métier
Les sites d'entreprise se divisent en général en deux catégories. La première est le type présentation : présentation de l'entreprise, liste de produits, coordonnées ; l'essentiel étant que l'information soit claire, que le chargement soit rapide et que le rendu soit bon sur mobile. Ce type de projet a un cycle court, l'accent portant sur le design et la structure du contenu.
La seconde catégorie est le type métier : avec réservation, commande, adhésion, tableau de bord de données. Il s'agit au fond d'un système léger, le site d'entreprise n'en étant que la porte d'entrée.
Prenons un cas concret. Une entreprise de maintenance d'équipements veut refondre son site vitrine, qui ne présentait auparavant que des photos de produits. Lors de la refonte, elle demande d'ajouter un « signalement de panne en ligne » : le client saisit le numéro de l'équipement, la description de la panne, téléverse une photo, et le back-office affecte automatiquement le dossier à l'ingénieur de la zone correspondante.
Il ne s'agit donc plus d'une refonte, mais de la création d'un système de tickets d'intervention. Un écart de prix de dix fois se joue souvent précisément sur ce genre de besoin : a-t-il été clarifié à l'avance ou non.
À faire : avant le lancement du projet, lister les fonctionnalités et annoter chacune « indispensable / souhaitable / à voir plus tard ». À éviter : ne pas écrire dans le contrat « fonctionnalités conformes à tel site » ; cette phrase équivaut à ne rien écrire.
Développement de mini-programme et développement d'App : demandez d'abord où sont vos utilisateurs
Beaucoup de clients annoncent d'emblée vouloir une App. Pas si vite : posez une question — vos utilisateurs sont-ils prêts à installer une App pour une seule fonction ?
S'il s'agit d'interactions légères comme la réservation, l'inscription ou la consultation de commandes, le développement de mini-programme est généralement plus rentable : pas de téléchargement, ouverture directe dans WeChat, coût de promotion faible. L'App convient mieux aux usages à haute fréquence, nécessitant des notifications push et l'accès à davantage de capacités de l'appareil.
Un décalage fréquent : une équipe de services de proximité passe plusieurs mois à développer une App, puis découvre au lancement que la majorité des utilisateurs ne veulent tout simplement pas l'installer, et doit finalement revenir ajouter un mini-programme.
À faire : commencer par un mini-programme pour valider le besoin, puis envisager l'App une fois le modèle éprouvé. À éviter : ne pas mener deux fronts en parallèle, le budget et l'énergie s'en trouveraient dilués.
Le système de gestion back-office est le plus souvent sous-estimé
Un front-office agréable et un back-office pénible à utiliser : c'est le problème résiduel le plus courant dans les projets externalisés.
Le système de gestion back-office ne semble pas destiné aux clients, mais il détermine l'efficacité quotidienne de votre équipe. Le contenu peut-il être importé en masse, les droits peuvent-ils être affinés par rôle, les opérations sont-elles journalisées, l'export de rapports est-il pratique ? Ces détails ne se voient pas lors d'une démonstration, mais éclatent au grand jour après un mois d'utilisation.
À faire : lors de la recette, ne pas se contenter de regarder les pages ; faire manipuler par les utilisateurs réels l'ensemble du flux, de la création à la validation jusqu'à l'export. À éviter : prévoir au contrat la livraison du code source et de la structure de la base de données, ne pas se contenter d'un programme qui tourne.
À quelle étape placer les tests de sécurité et les tests d'ingénierie inverse
Beaucoup considèrent la sécurité comme une affaire d'après-lancement ; en réalité, elle doit intervenir dès la phase de développement web.
La pratique courante : une fois le développement terminé, réaliser une campagne de tests de sécurité du site, vérifiant les points de base que sont les accès non autorisés, les injections, le téléversement de fichiers et l'authentification des interfaces. Pour les systèmes impliquant des paiements et des informations utilisateurs, cette étape ne peut être omise.
Les tests d'ingénierie inverse servent plutôt à l'intégration d'interfaces tierces, au diagnostic d'appels anormaux et à la vérification de la fiabilité du chiffrement des données. Il ne s'agit pas d'une attaque, mais de comprendre le comportement réel du système dans un cadre autorisé.
À faire : inscrire les tests de sécurité dans les jalons du projet, comme condition obligatoire avant la mise en ligne. À éviter : les tests doivent se dérouler dans le cadre d'une autorisation écrite et d'un périmètre convenu ; en clarifiant les limites, les deux parties sont tranquilles.
Dans quels cas faire appel à MIC Studio
Tous les projets ne se prêtent pas à l'externalisation, et tous ne justifient pas non plus de constituer une équipe interne.
Les cas plutôt adaptés : le besoin est déjà relativement clair, mais vous n'avez pas de ressource de développement stable en interne ; le projet a une date de mise en ligne précise et nécessite une petite équipe capable de répondre du résultat ; ou bien un système existant requiert des travaux spécialisés comme des tests de sécurité ou un diagnostic d'interfaces.
Les cas moins adaptés : le stade où le besoin évolue encore fréquemment et où même les utilisateurs cibles ne sont pas définis. À ce moment-là, il vaut mieux d'abord mener une étude et un prototype plutôt que d'entrer directement en développement.
MIC Studio réalise du développement de sites d'entreprise, de mini-programmes, d'App et de scripts, et assure également des tests de sécurité de sites et des tests d'ingénierie inverse. La structure est de taille modeste, avec l'avantage de circuits de communication courts : on trouve directement la personne qui fait le travail.
Trois conseils applicables immédiatement
Premièrement, rédigez le besoin sous forme de liste de fonctionnalités, en indiquant clairement les priorités, avant de demander des devis. Plus la liste est précise, plus les devis sont comparables.
Deuxièmement, précisez au contrat les livrables : code source, base de données, documentation de déploiement, droits des comptes, ainsi que la durée du support de maintenance après la mise en ligne.
Troisièmement, prévoyez du temps pour la recette, faites parcourir le flux complet par les utilisateurs réels ; ne signez pas après deux clics dans l'environnement de démonstration.
La réussite d'un projet dépend à 80 % de la clarté des quelques pages rédigées avant son démarrage.