Back to blog
Jun 11, 2025
8 min read

Ma revanche sur C# et .NET : créer un raccourcisseur d'URL

Retour sur mes débuts difficiles avec C# à 17 ans, et comment j'ai finalement créé mon premier projet back-end avec .NET après 10 ans de développement web.

👶 Retour en arrière : mes premiers pas avec C#… et mes premières cicatrices

Il y a un peu plus de 10 ans, alors que j’avais à peine 17 ans, je me suis lancé dans la programmation en utilisant Unity Engine. J’avais réussi à coder un petit jeu FPS tout seul avec C#, et même si le projet n’était pas parfait, j’en étais fier.

Mais cette première immersion dans le monde de la programmation m’a aussi un peu traumatisé. Curieux, j’avais voulu tester C++ avec Unreal Engine 4, pensant que c’était “plus simple”. Spoiler : je me suis pris un mur. Trop complexe (bien plus que C#), trop technique, trop brutal pour un ado autodidacte. Cette double claque m’a poussé à tout arrêter pendant un moment.

🌐 L’appel du web : un virage décisif

À la suite de cette expérience, j’ai pris une décision importante : revenir aux bases, et apprendre le développement web. J’ai commencé par HTML, CSS, JavaScript, puis j’ai plongé dans React, Vue, Nuxt, Next, bref… j’ai exploré tout un écosystème moderne, vibrant, créatif et beaucoup plus accessible.

Grâce à ça, j’ai développé des dizaines de projets web. Je me suis senti à l’aise dans ce monde où le front-end et l’UX priment, et où les feedbacks sont instantanés. J’ai même un blog maintenant (celui sur lequel tu lis cet article).

Mais au fond de moi, C# était resté un terrain que je n’avais jamais vraiment conquis.

🎯 Le projet : créer un raccourcisseur d’URL avec C# et .NET

Aujourd’hui, comme une forme de revanche ou de défi personnel, j’ai décidé de reprendre C#, mais cette fois dans un contexte totalement différent : le back-end avec .NET. Je voulais voir si j’étais enfin prêt à dompter cette techno.

Je me suis fixé un objectif simple (en apparence) : développer un service de raccourcissement d’URL, comme Bitly, mais fait maison.

📦 Le point de départ : un tutoriel ASP.NET Core

Je suis tombé sur un tutoriel expliquant comment créer une API Web REST en ASP.NET Core, en utilisant Entity Framework, Swagger, et PostgreSQL.

Voici les grandes étapes que j’ai suivies :

dotnet new webapi -n UrlShortener
cd UrlShortener
mkdir Models Data Controllers

Puis, j’ai configuré la base de données, branché EF Core, et commencé à créer mes fichiers UrlMapping.cs, AppDbContext.cs, et UrlController.cs.

😵 Les galères : migrations, EF Core, concepts flous

Rien que la commande suivante :

dotnet ef database update

… m’a donné du fil à retordre. Je me suis pris des erreurs liées à la base PostgreSQL, au fichier appsettings.json mal configuré, au tool dotnet-ef non installé… Bref, j’ai googlé, testé, re-googlé, demandé à ChatGPT, et à force de persévérance, ça a fini par marcher.

Ensuite, j’ai découvert des notions nouvelles pour moi :

DbContext

Dans Entity Framework Core (EF Core), DbContext est la classe principale qui représente une session avec la base de données. Elle est utilisée pour interagir avec les données, effectuer des requêtes, et gérer les entités dans la base de données. Il s’agit de la couche d’abstraction entre ton application et ta base de données. Un DbContext contient des DbSet (une collection d’entités) et gère les opérations CRUD (Create, Read, Update, Delete) pour ces entités. En d’autres termes, c’est le point de contact pour manipuler les données dans ta base via EF Core.

Dependency Injection (DI)

Dependency Injection est un concept fondamental en .NET et dans beaucoup d’autres frameworks modernes. Il s’agit d’un principe de conception qui consiste à fournir des dépendances à une classe ou à un objet de l’extérieur, plutôt que de les créer en interne. Cela permet de rendre ton application plus modulaire, testable, et maintenable.

Par exemple, au lieu que ta classe ait directement des instances de services ou d’objets qu’elle utilise, elle recevra ces objets (ses “dépendances”) par le biais de son constructeur, d’une méthode, ou d’une propriété. Cela est souvent configuré par l’injection de dépendances via le conteneur de services de .NET.

MapControllers()

La méthode MapControllers() est utilisée dans ASP.NET Core pour configurer la gestion des routes pour tes contrôleurs d’API dans une application web. Elle permet de lier les routes HTTP (GET, POST, PUT, DELETE, etc.) aux actions dans tes contrôleurs. Cette méthode indique au framework ASP.NET Core de rechercher les contrôleurs dans ton application et d’enregistrer leurs méthodes comme des endpoints accessibles via des URL.

Avant .NET 6, la configuration des contrôleurs se faisait dans le fichier Startup.cs. Avec la version simplifiée de .NET 6, cette configuration se fait maintenant directement dans Program.cs, et MapControllers() est utilisé pour enregistrer les routes de tes API.

Swagger

Swagger est un framework pour la documentation d’API REST. Dans ASP.NET Core, il est utilisé via un package appelé Swashbuckle pour générer automatiquement une interface utilisateur interactive qui permet de tester et d’explorer les endpoints d’une API. Il fournit une interface web (souvent accessible à http://localhost:5000/swagger) où tu peux voir toutes les routes disponibles, envoyer des requêtes, et obtenir des réponses directement depuis le navigateur. C’est un excellent moyen pour les développeurs de tester et documenter une API, tout en offrant aux autres utilisateurs un moyen facile de comprendre son fonctionnement.

Program.cs sans Startup.cs (merci .NET 6)

Avant .NET 6, la configuration d’une application ASP.NET Core se faisait principalement dans deux fichiers : Program.cs et Startup.cs. Startup.cs était utilisé pour configurer les services de l’application (comme l’injection de dépendances, les middlewares, la configuration de la base de données, etc.).

Depuis .NET 6, Microsoft a simplifié le processus en regroupant tout dans un seul fichier : Program.cs. Ce fichier est maintenant responsable de la configuration des services et de l’application. En résumé, .NET 6 a consolidé la configuration dans Program.cs, ce qui rend le code plus concis et réduit la complexité.

Heureusement, la communauté .NET est active, la documentation Microsoft est solide (même si parfois trop verbeuse), et les forums, Stack Overflow et ChatGPT ont été des soutiens quotidiens.

✨ Le moment eureka : Swagger fonctionne !

Quand j’ai enfin lancé mon app avec dotnet run et accédé à http://localhost:5260/swagger, j’ai eu un vrai frisson. L’interface était là, je pouvais :

  • envoyer une URL via POST /url
  • récupérer un lien court
  • tester le lien court via GET /{code} et être redirigé vers l’original

Le tout stocké en base via EF Core. C’était propre, fonctionnel, et… j’avais codé ça moi-même en C# !

🎨 Une interface HTML pour aller plus loin

Mais bon, passer par Swagger, ce n’est pas très user-friendly. Alors j’ai entamé la création d’une interface front-end simple avec un formulaire HTML dans le dossier wwwroot.

On a intégré une page HTML minimaliste avec du JavaScript pour appeler mon API, et ça a très bien marché. Une belle preuve de l’intégration possible entre front et back dans un projet ASP.NET.

💡 Ce que ce projet m’a appris

  • C# a évolué. Ce n’est plus le langage effrayant de mes débuts sur Unity
  • .NET est ultra puissant, notamment pour faire du back-end solide
  • EF Core et Swagger sont des outils qui simplifient énormément la vie une fois bien maîtrisés
  • Le web m’a appris à apprendre, et c’est ça qui m’a permis de réussir ce projet

🧱 Et maintenant ?

Je suis super motivé à continuer ce genre de projets. J’ai quelques idées pour la suite :

  • Ajouter des statistiques de clics
  • Autoriser la personnalisation du code court
  • Mettre en place une expiration automatique des liens
  • Créer un dashboard admin en React ou Vue

✍️ Conclusion

Ce projet, c’était plus qu’un simple exercice technique. C’était une façon de me réconcilier avec un langage que j’avais fui il y a 10 ans. Une revanche, mais aussi un symbole de mon évolution en tant que développeur.

C’est toujours bon de sortir de sa zone de confort. Oui, j’ai un peu galéré. Oui, j’ai douté. Mais j’ai aussi appris, progressé, et j’en suis heureux.

Les outils sont là, les ressources sont là… et tu n’es jamais seul, les réponses aux problèmes qu’on rencontre sont (la plupart du temps) déjà sur la toile !

Vous pouvez trouver le repo Github de ce projet ici.