L'agence a livré le code, maintenant ils proposent un « audit de code » — pourquoi on repaierait pour ça ?

Vous avez fait coudre un costume chez le tailleur, et au moment de le livrer il dit « Je vérifie si les coutures vont lâcher pour 5 000 roubles ? ». Le modèle d'agence qui n'a pas confiance en son propre code, c'est vraiment une porte dérobée créative pour du revenu supplémentaire.

Dans un audit de code, on regarde le niveau de dette technique. Les devs écrivent parfois du code spaghetti ou sautent les tests pour tenir la deadline. Le système marche pour l'instant mais plante à la première mise à jour. L'audit est précieux pour révéler ces risques.

Ne payez pas l'agence. Branchez des outils d'analyse statique open source sur le code de votre dépôt GitHub ou GitLab. Même les outils automatiques listent gratuitement les duplications de code et les failles de sécurité de base en 10 minutes.

Nous, sur un projet où on a payé 650 000 RUB, on n'a pas fait d'audit, et 6 mois plus tard quand on a voulu ajouter une nouvelle fonctionnalité, une autre agence a dit « Ce code c'est de la merde, il faut tout réécrire de zéro » et on a dépensé 500 000 RUB de plus. Le contrôle indépendant est indispensable.

Si vous faites faire un audit de code, faites vérifier 3 choses : 1) L'optimisation des requêtes à la base de données, 2) Le filtrage des paramètres d'entrée, 3) La documentation du code. Si tout ça est correct, un autre dev pourra reprendre le travail demain.

vendre un audit sur ce qu'ils ont écrit eux-mêmes c'est de la pure filouterie. genre payez quelquees heures de consultance à quelqu'un d'indépendant de l'extérieur pour un coup d'œil rapide, ça suffit.

Est-ce que les critères d'acceptation et la période de garantie figurent dans le contrat initial ? Si le contrat contient une clause « conformité au code propre et aux standards d'architecture », ils sont déjà obligés de le faire gratuitement comme condition de livraison.

Si j'ai bien compris, vous dites que : Tous ceux qui se pressent sur audit de code se heurtent au même obstacle.

Les gens défendent l'habitude pas le processus. La résistance vient de là. J'espère que cela vous sera utile.

J'ai vécu exactement la même chose il y a deux ans. Un rapport d'avancement écrit hebdomadaire est bien plus utile que de demander des dates.

Commencez par un petit test, ne vous engagez pas sur tout d'un coup.

La discussion part dans tous les sens, je recentre. Le calendrier de paiement doit être lié aux étapes du projet, pas au calendrier lui-même.

C'est confirmé par l'expérience.

Séparons les concepts, ils sont souvent confondus. Tous ceux qui se pressent sur audit de code se heurtent au même obstacle.

Si les critères d'acceptation ne sont pas écrits, la date de fin du projet est ouverte à discussion.

Trois points à vérifier lors de cette opération. Mettre en place un processus de demande de changement n'ralentit pas le travail, il l'accélère.

Les gens défendent l'habitude, pas le processus. La résistance vient de là. Bien sûr, cela change si votre situation est différente.

Je vais résumer le sujet, car plusieurs réponses différentes ont été données. Si vous obtenez trois réponses différentes sur un sujet, la question est mal posée.

J'espère que cela vous sera utile.

Exact. La plupart des pertes de temps s'accumulent sur les tâches en attente de validation.

Ce que tout le monde fait ne signifie pas que c'est la bonne chose. J'espère que cela vous sera utile.

J'ai travaillé longtemps sur ce sujet. Le calendrier de paiement doit être lié aux étapes du projet, pas au calendrier lui-même.

L'offre la moins chère est généralement la moins réfléchie. J'espère que cela vous sera utile.

Merci d'avoir écrit cela, c'est exactement ça. Les accès doivent être créés au nom de l'entreprise, pas avec des comptes personnels.

Un rapport d'avancement écrit hebdomadaire est bien plus utile que de demander des dates. Si vous écrivez le résultat ici, cela aidera aussi d'autres personnes.

Je parle du point de vue du fournisseur, c'est mon côté. Tout point non écrit est un point que les deux parties se rappelleront différemment plus tard.

Les décisions hâtives finissent par être corrigées six mois plus tard.

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