Premier vrai mandat comme consultant: on m’a donné un badge d’accès, un poste avec un gros écran pis un projet déjà commencé chez le client. Pas de période d’échauffement de trois semaines. Le développeur senior m’a montré une application Windows en VB.NET, m’a pointé un formulaire de saisie de commandes, pis il m’a dit: « Le client veut qu’on valide les champs avant d’enregistrer dans la base. Es-tu capable de regarder ça aujourd’hui? »

C’était ça, mon entrée dans le métier. Pas une grande théorie sur l’architecture. Un formulaire, des champs, une base de données SQL Server, pis du monde chez le client qui attendait que ça marche.

Le code qui sert à quelque chose

À l’école, je codais des affaires qui finissaient dans un dossier Devoirs. Là, le code allait servir à des vraies personnes qui rentrent des vraies commandes. La différence, je l’ai sentie tout de suite.

Mon premier vrai morceau, c’était de connecter le formulaire à la base avec ADO.NET. Ouvrir une SqlConnection, monter un SqlCommand, lire le résultat, fermer la connexion. Sur papier, ça a l’air simple.

Dim cn As New SqlConnection("Server=SRV01;Database=Commandes;Integrated Security=SSPI;")
Dim cmd As New SqlCommand("INSERT INTO Commande (NoClient, Montant) VALUES (@no, @montant)", cn)
cmd.Parameters.AddWithValue("@no", txtNoClient.Text)
cmd.Parameters.AddWithValue("@montant", txtMontant.Text)
cn.Open()
cmd.ExecuteNonQuery()
cn.Close()

Ma première vraie erreur

La première version, j’avais oublié de fermer la connexion proprement. Tant que je testais tout seul, tout allait bien. Mais dès que deux ou trois personnes utilisaient le formulaire en même temps, l’application se mettait à ralentir, pis à planter.

Oh non. J’avais laissé des connexions ouvertes partout.

Le senior m’a montré le Try...Catch...Finally, pis l’idée de toujours fermer la connexion dans le Finally, même quand ça plante. Pas glorieux comme leçon, mais je l’ai jamais réoubliée.

Try
    cn.Open()
    cmd.ExecuteNonQuery()
Catch ex As SqlException
    MessageBox.Show("Erreur en sauvegardant la commande.")
Finally
    cn.Close()
End Try

La validation, c’est pas juste un détail

Le client voulait valider avant d’enregistrer, pis j’ai vite compris pourquoi. Du monde qui rentre des données, ça met des montants avec des virgules, des espaces, des champs vides, du texte dans une case de chiffres. Si tu valides pas, c’est la base qui ramasse le dégât.

J’ai commencé simple: vérifier que le numéro de client existe, que le montant est un vrai nombre, que les champs obligatoires sont remplis. Rien de fancy. Mais ça a coupé une grosse partie des appels au support la première semaine.

Dans ma tête, le flux ressemblait à ça:

flowchart TD
    A[Utilisateur remplit le formulaire] --> B{Champs valides ?}
    B -- Non --> C[Message d'erreur clair]
    C --> A
    B -- Oui --> D[INSERT dans SQL Server]
    D --> E{Erreur SQL ?}
    E -- Oui --> F[Catch + message + Finally ferme la connexion]
    E -- Non --> G[Commande enregistrée]

Ce que ça m’a appris

Ma première leçon de vrai développeur, c’est pas une techno. C’est que le code vit dans les mains d’autres personnes. Une affaire qui marche sur mon poste peut planter dès que trois personnes l’utilisent en même temps.

J’ai aussi compris que les erreurs des utilisateurs sont pas des exceptions: c’est la normale. Le travail, c’est de prévoir le champ mal rempli, la connexion qui lâche, le réseau qui ralentit.

Premier mois, premier vrai code en production. C’était imparfait, je revenais souvent corriger des affaires. Mais à chaque bug réglé, je comprenais un peu mieux pourquoi le métier, c’est pas juste écrire des lignes: c’est livrer quelque chose qui tient le coup quand le vrai monde s’en sert.