Where can i write user stories ?

I sometimes use excel for this if there are now better tools available.

You should get a tool. But in order to get a tool, you'll need to have a better handle on what your requirements are.

If your team is physically colocated and working from the same site, the tool could be as simple as sticky notes on a wall or cards on a corkboard. However, even if you are fully colocated and working entirely from a single location now, I'd advise against this approach. If you ended up in a situation where the team wasn't colocated or someone needed to work from a remote location (even if temporarily), it's much more difficult to keep this kind of system up-to-date and informative.

A spreadsheet in your favorite editor, preferably in the cloud, would work. This could be Microsoft Excel shared through Office 365 or Sharepoint, Google Sheets and Google Drive, or something like Airtable. A tool like Trello that supports cards, boards, simple workflows, and has some level of automation can also be straightforward.

An issue tracker is a good tool, too. Although it can be overwhelming and difficult to configure for someone without experience, Jira can be a good tool. If you're building software, tools like GitHub, GitLab, and even Bitbucket have built-in issue trackers that can be used.

What you can use really depends on your context and specific requirements. For example, I work in an environment that supports regulated entities as customers. A tool like Jira that has audit trails, integrations with other tools (like source code control and test case management), and more robust permissions is very important. These things may not matter so much for you and you can deal with a lighterweight tool. Your requirements may evolve over time, so the ability to export data in different formats for importing into a different tool may be something to consider.

So I was wondering, the best way to manage my user stories and the backlog.

Collaboratively, with Developers who understand and get the work Done, and with a clear Product Owner who is accountable for content, ordering, and the maximization of value. Let these creative professionals have the right conversations each story should provoke.

So I was wondering, the best way to manage my user stories and the backlog.

First question that came to mind when reading your post was that you are seeing all of the stories as yours and not as the team's.  Why are you the one writing user stories?  Why isn't the team doing it? 

Now to provide you some suggestions on your request.

Anything that allows your team to collaborate on statements of value, can be ordered, and is easily visible.  I agree with @Thomas Owens that having a tool is good but you have to know what your requirements are before getting the tool. If this is a brand new idea start with something that is available to you.  Spreadsheets can be useful as you can add status columns that can be filtered and the rows can easily be ordered.  But that is not the only way. I worked with one company that was starting out the journey to agile that had been creating requirements documents.  We started to split the big document into smaller documents and then linked to them from an "overview" (i.e. an Epic).  Each document was stored in subfolders of a managing folder. Epics stayed in the managing folder, the individual requirements documents were moved through a series of sub folders that would represent statuses.  It was not the easiest way to manage but it worked well enough for us to discover what kind of features we wanted in our management software. 

Base your initial decision on what your company already is used to.  Involve the entire team in the decision as they are the ones that the Product Backlog is intended to help. You would be amazed at what a team of technical people can come up with.  And remember that as with all things agile, this could be an incremental transition.  Follow the empirical process by trying something, inspect it for its effectiveness, adapt as needed and repeat for as long as you are building software.  @Ian Mitchell's response would be your vision and goal that guides you through the evolution.

Thanks everyone for your replies. I ended up writing the US on an excel sheet and started a trello board as a kanban.

@Daniel : We already have a general requirements document and it will be transformed into user stories. Those will be written in collaboration with the business team and the IT team.

Now, I am uncertain about how to write good acceptance criteria.  I already have written the titles of my US (as a , i want to, so than i can), but I don't know how to make a difference between a business rule and an AC. 

Can a user story be written without business rules ? 

A user story can be written without acceptance criteria.  User stories are not mentioned in the Scrum Guide. They are a practice that many people have found useful.  Look at @Thomas Owens' response that was posted yesterday on this thread https://www.scrum.org/forum/scrum-forum/49418/product-backlog-items. He states it very well. 

Thank you very Daniel. I am new to the agile world and the department I work for (IT department) still conducts projects with V method so there is no one I can rely on when I need advice ...

I read the thread and I am reading right now the scrum guide. Indeed user stories are not mentionned in the guide.

My question is, if user stories are not mandatory, what can replace it in the product backlog ? 

A Product Backlog item needs to describe the need for the product.  The format can be anything that you want it to be as long as it presents all the information that the team needs in order to understand, make a plan to satisfy the need, and validate that the need is provided. 

I've worked with teams that did a scaled down version of old style requirements documents. I've worked with teams that used a user story like format. I've worked with teams that worked together and captured the information needed in various formats depending on the need being described. 

In the end it is up to the team that is working on the Product Backlog Items to determine the best way to capture them. They should worry less about standardized format and focus on capturing content that is useful.