Faut-il passer par une agence de dev ou un consultant, quelle est vraiment la différence ?

Si personne ne touche au dev chez vous, n'allez pas négocier en direct avec une agence. La marche à suivre : 1) Définir le périmètre avec le consultant, 2) Faire chiffrer ce cahier des charges par au moins trois agences, 3) Intégrer les critères de recette et pénalités de retard au contrat avec validation du consultant.

L'année dernière, on a sollicité une agence direct avec 400.000 TL de budget pour notre logistique. On avait rédigé le cahier des charges nous-mêmes avec nos mots. Résultat : projet annoncé sur 5 mois qui en a pris 14, et facture finale à 650.000 TL à cause des avenants. Le coût du consultant nous paraissait cher au début, mais on a vite compris notre douleur.

Attention quand même, ne faites pas une confiance aveugle à tous les consultants du marché. Certains touchent des commissions discrètes de la part de certaines agences. Ils font semblant d'être impartiaux mais vous orientent en douce vers leur partenaire. Vérifiez minutieusement leurs références.

Le boulot principal d'une boîte de dev, c'est de concevoir l'architecture et de coder, mais la plupart se contentent de survoler l'analyse métier à partir de vos seules explications. Le consultant, lui, va définir les critères d'acceptation technique, de la normalisation du schéma de base de données jusqu'à la flexibilité de l'architecture API. C'est aussi lui qui vérifie la documentation et la propriété du code source lors de la livraison.

on a vécu le même dilemme. quand on n'arrive pas à exprimer précisément son besoin, la boîte de dev fait logiquement ce qu'elle a compris, et au final les deux parties sont perdantes puis si vous avez le budget, un consultant est clairement une bouée de sauvetage, ça vous évitera la moitié des maux de tête.

même si vous prenez un consultant désignez un référent en interne pour suivre le truc mais sinon le consultant va pondre des rapports la boîte va coder mais les emplloyés utiliseront pas le système, et l'argent sera encore jeté par les fenêtres.

Est-ce que les boîtes de dev avec lesquelles vous discutez ont déjà réalisé un projet d'ERP ou de suivi de stock dans l'emballage ou la production industrielle comme vous ? S'ils ont de la bouteille dans votre secteur ça peut le faire sans consultant, mais s'ils découvrent complètement le milieu, le process va être très douloureux.

Pour résumer : le consultant traduit vos besoins dans le langage des développeurs et protège vos intérêts, tandis que la société de dev code et fait tourner le projet. Si le budget le permet, combiner les deux reste l'option la plus sûre.

Correction : je me suis trompé sur le chiffre, c'était un peu plus bas.

la discussion part dans tous les sens je recentre. dans un système repris, le plus coûteux sont les dépendances inconnues.

Vous avez raison, je suis aussi passé par là. Ce qui nous faisait perdre le plus de temps, c'était l'absence de clarté sur qui prenait les décisions.

Un code sans documentation d'installation ne vous appartient pas, même si vous l'avez. Je le note au cas où.

J'ai vécu la même chose.

Je vais raconter ce qui m'est arrivé, ça pourrait vous servir. Le calendrier de paiement doit être lié aux étapes du projet, pas au calendrier lui-même.

Je le note au cas où.

Exact. Avant de décider, regardez quelles données vous avez en main.

Bon courage.

Absolument. Si j'ajoute quelque chose : Les décisions hâtives finissent par être corrigées six mois plus tard.

Merci, c'était exactement la réponse que je cherchais.

La discussion part dans tous les sens, je recentre. Commencez par un petit test, ne vous engagez pas sur tout d'un coup.

Je vais essayer.

La solution qui semble bon marché finit souvent par coûter cher. Le calendrier de paiement doit être lié aux étapes du projet, pas au calendrier lui-même.

Le système continue de vivre après la livraison ; la maintenance est un poste à part. Bon courage.