Votre idée mérite une équipe à la hauteur

Quand le sur mesure n'est pas la bonne réponse

Autant le dire franchement, puisque c'est ce que nous vous dirons de toute façon lors du premier échange : dans une bonne partie des cas, développer sur mesure est une erreur.

Si un logiciel du marché couvre quatre-vingts pour cent de votre besoin, l'achat est presque toujours plus rationnel. Vous payez un abonnement au lieu d'un développement, vous bénéficiez des évolutions faites pour des milliers d'autres clients, et vous n'assumez ni la maintenance ni la dette technique. Adapter votre processus à l'outil coûte généralement moins cher que l'inverse.

Le sur mesure devient pertinent quand votre manière de travailler est votre avantage concurrentiel et qu'aucun outil ne la reproduit, quand vous payez des licences pour dix personnes alors que trois utilisent réellement le logiciel, quand vos équipes passent leurs journées à recopier des données d'un système vers un autre, ou quand un outil existant vous impose une limite qui vous coûte du chiffre d'affaires.

Notre premier réflexe est donc de chercher ce qui existe déjà. Si nous trouvons, nous vous le disons, même si cela nous fait perdre le mandat.

Un choix technique se juge dans cinq ans

Nous privilégions des technologies ennuyeuses au sens noble du terme : largement adoptées, solidement documentées, et pour lesquelles vous trouverez des développeurs sans difficulté. C'est un critère qui compte davantage que l'élégance d'un framework à la mode.

La raison est simple. Le jour où vous voudrez internaliser le développement, changer de prestataire ou simplement faire évoluer l'application trois ans après nous, la question ne sera pas de savoir si la technologie était brillante. Elle sera de savoir si quelqu'un d'autre peut reprendre le code sans tout réécrire. Un choix exotique vous enferme, y compris chez nous, et ce n'est pas un service à vous rendre.

Concrètement : le code est documenté, testé sur les parties critiques, livré dans votre dépôt Git avec l'historique complet, et déployé par une chaîne automatisée que vous pouvez reprendre.

Commencer petit, et le penser dès le départ

Nous recommandons presque systématiquement de démarrer par une version réduite, mise entre les mains de vos utilisateurs le plus tôt possible. Non par prudence budgétaire, mais parce que le cahier des charges initial se révèle toujours partiellement faux.

C'est un phénomène constant : tant que personne n'utilise l'outil, les besoins exprimés relèvent de l'intuition. Trois semaines après la mise en service, vos équipes vous diront que la fonctionnalité jugée indispensable ne sert à personne, et qu'un détail passé sous silence leur fait perdre une heure par jour. Découvrir cela sur une première version coûte peu. Le découvrir après six mois de développement complet coûte beaucoup.

Nous construisons donc les fondations pour qu'elles supportent la suite, mais nous ne développons pas la suite avant que vous ayez confirmé qu'elle est nécessaire.