Comant

During a three-month full-stack internship at CoreTechnologie, I worked on Comant, the company's internal application for managing projects, organizing teams and distributing work through tickets. I joined the project shortly before its deployment on the company's servers, so my first weeks were spent fixing bugs and polishing details ahead of the release.

Once the application went live, my role shifted: the users were my own colleagues, and I gathered their feedback directly to identify pain points, improvements and new features worth building. I worked alongside my supervisor, splitting the tasks between us and agreeing on deadlines for each new feature we shipped.

Comant has a Symfony/PHP backend with an object-oriented domain model and a MySQL database, paired with a front end built to be immediately usable by non-technical colleagues.

What I built and worked on:

• Backend architecture : Object-oriented PHP with the Symfony framework, with dedicated classes for tickets, users and projects, and full CRUD operations against a MySQL database.
• Help section : A page where administrators can write and maintain documentation on how to use the application, its domain-specific vocabulary, and internal best practices.
• Ticket search : A search page letting users combine filters (project, product, creator, assignee, and more) to find the tickets they need, with the ability to save a search and reuse it later.
• Multi-view mode : Previously, selecting a ticket or a project opened its details in a new tab. I implemented a split layout where the list stays in the upper half of the page and the details render below, so users can browse through items and read their details without ever leaving the page.
• Interface and UX : I mocked up interfaces in Figma before building them with HTML, CSS, JavaScript and Bootstrap. I paid attention to the details of the user experience, making sure that the application was easy to use and that the most important information was always visible.

What made this project valuable was the constant communication with the people actually using the application. Being able to talk directly to my colleagues meant I could hear their frustrations firsthand, and turn vague requests into concrete features that made their daily work easier.

This was also my first professional experience. I paid close attention to the quality of the code I delivered, following the practices my supervisor passed on to me, and I learned how code makes its way to production using Perforce as the version control system. Working to agreed deadlines forced me to organize my own time, and translating user requests into well-scoped features turned out to be as much of a skill as writing the code itself.

My supervisors were very satisfied with my work and valued the help at a moment when it counted: I joined right at deployment and through the first weeks of real usage, a demanding period where developers need to react quickly to whatever surfaces. The features I built were well received by my colleagues, who used them daily.